Methods, apparatus and systems for enabling managed remote access

ABSTRACT

Methods, apparatus, and systems are disclosed for handover of a Wireless Transmitter/Receiver Unit (WTRU) moving between a local network and another network. The WTRU established a local IP access (LIPA) session in the local network via a first Access Point (AP). The method includes receiving, by a second AP in the other network, a request to connect to the other network; and transitioning the LIPA session in the local IP network to a managed remote access (MRA) session in the other network. The transitioning includes establishing a path between the first AP and the second AP via a gateway, and informing the gateway of the transition to the MRA session.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 13/626,957, filed on Sep. 26, 2012, which claims the benefit of U.S.Provisional Application No. 61/541,825, filed on Sep. 30, 2011, thecontents of each of which are incorporated by reference herein.

FIELD OF INVENTION

The field of this invention relates to wireless communications and, moreparticularly, methods, apparatus and systems for enabling managed remoteaccess.

BACKGROUND OF THE INVENTION

LIPA (local IP access) may provide an IP connection to a local network(LN) using radio access of a Home eNode B and/or a Home Node B (e.g.,referred to as H(e)NB).

SUMMARY

Embodiments of the disclosure are directed to methods, apparatus, andsystems for handover of a Wireless Transmitter/Receiver Unit (WTRU)moving between a LN and another network. The WTRU may have established alocal IP access (LIPA) session in the LN via a first Access Point (AP).The method may include receiving, by a second AP in the other network, arequest to connect to the other network; and transitioning the LIPAsession in the local IP network to a managed remote access (MRA) sessionin the other network. The transitioning may include establishing a pathbetween the first AP and the second AP via a gateway, and informing thegateway of the transition to the MRA session.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the Detailed Descriptionbelow, given by way of example in conjunction with drawings appendedhereto. Figures in such drawings, like the detailed description, areexamples. As such, the Figures and the detailed description are not tobe considered limiting, and other equally effective examples arepossible and likely. Furthermore, like reference numerals in the Figuresindicate like elements, and wherein:

FIG. 1A is a diagram illustrating a representative communication systemin which one or more disclosed embodiments may be implemented;

FIG. 1B is a diagram illustrating a representative wirelesstransmit/receive unit (WTRU) that may be used within the communicationsystem illustrated in FIG. 1A;

FIGS. 1C, 1D, and 1E are system diagrams of representative radio accessnetworks and representative core networks that may be used within thecommunication system illustrated in FIG. 1A;

FIG. 2 is a diagram illustrating a representative communication systemsimilar to that of FIG. 1D;

FIG. 3 is a diagram illustrating another representative communicationsystem including a plurality of local gateways (LGWs) each withrespective H(e)NBs;

FIG. 4 is a diagram illustrating a portion of the representativecommunication system of FIG. 3 with a WTRU moving and connecting to(e.g., accessing the system via) different respective H(e)NBs along amovement path;

FIG. 5 is a diagram illustrating selected IP Traffic Offload (SIPTO);

FIG. 6 is a diagram illustrating user data offload to the Internet via aLGW that may be connected to a HeNB subsystem;

FIG. 7 is a diagram illustrating a representative standalone LGWarchitecture for a HeNB subsystem in which the HeNB may interface withthe HeNB GW via an S1-U interface;

FIG. 8 is a diagram illustrating another representative standalone LGWarchitecture for an HNB subsystem in which the HNB may interface withthe HNB GW via a luh interface and HNB may interface with LGW via an Sxxinterface for an Evolved Packet System (EPS);

FIG. 9 is a diagram illustrating a further representative standalone LGWarchitecture for an HNB subsystem in which the HNB may interface withthe HNB GW via the luh interface and HNB may interface with LGW via anSxx interface for a Universal Mobile Telecommunications System (UMTS);

FIG. 10 is a diagram illustrating an additional representativestandalone LGW architecture for an HeNB subsystem in which the HeNB mayinterface with the HeNB GW via an S1-U interface and the LGW is on an S1path;

FIG. 11 is a diagram illustrating a representative standalone LGWarchitecture for an HNB subsystem in which the HNB may interface withthe HNB GW via the luh interface for an Evolved Packet System (EPS) andthe LGW is on a luh path;

FIG. 12 is a diagram illustrating a representative standalone LGWarchitecture for an HNB subsystem in which the HNB may interface withthe HNB GW via the luh interface for UMTS and the LGW is on the luhpath;

FIG. 13 is a diagram illustrating a handover procedure including atransition between a LIPA session and a MRA session using an eNB in amacro network;

FIG. 14 is a diagram illustrating a handover procedure including atransition between a LIPA session and a MRA session using a HeNB withinanother LN;

FIG. 15 is a diagram illustrating a representative data path for adownlink for a MRA session;

FIG. 16 is a diagram illustrating a representative Service Requestprocedure;

FIG. 17 is a diagram illustrating representative access controlscenarios;

FIG. 18 is a diagram illustrating a WTRU moving out of a LN while inidle mode;

FIG. 19 is a flow chart illustrating a representative handover method;

FIG. 20 is a flow chart illustrating a representative setup method;

FIG. 21 is a flow chart illustrating another representative handovermethod;

FIG. 22 is a flow chart illustrating a further representative handovermethod;

FIG. 23 is a flow chart illustrating an additional representativehandover method;

FIG. 24 is a flow chart illustrating a representative terminationmethod; and

FIG. 25 is a flow chart illustrating yet another representative handovermethod;

FIG. 26 is a flow chart illustrating a representative selection method;

FIG. 27 is a flow chart illustrating a representative setup method;

FIG. 28 is a flow chart illustrating a representative setup method; and

FIG. 29 is a flow chart illustrating a representative method.

DETAILED DESCRIPTION

Although the detailed description is illustrated and described hereinwith reference to specific embodiments, the invention is not intended tobe limited to the details shown. Rather, various modifications may bemade in the details within the scope and range of equivalents of theclaims and without departing from the invention.

FIG. 1A is a diagram of a representative communications system 100 inwhich one or more disclosed embodiments may be implemented. Thecommunications system 100 may be a multiple access system that providescontent, such as, data, video, messaging, broadcast, etc., to multiplewireless users. The communications system 100 may enable multiple usersto access such content through the sharing of system resources,including wireless bandwidth. For example, the communications systems100 may employ one or more channel access methods, such as code divisionmultiple access (CDMA), time division multiple access (TDMA), frequencydivision multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrierFDMA (SC-FDMA), and the like.

As shown in FIG. 1A, the communication system 100 may include wirelesstransmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a radioaccess network (RAN) 104, a core network 106, a public switchedtelephone network (PSTN) 108, the Internet 110, and other networks 112,though it will be appreciated that the disclosed embodiments contemplateany number of WTRUs, base stations, networks, and/or network elements.Each of the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of deviceconfigured to operate and/or communicate in a wireless environment. Byway of example, the WTRUs 102 a, 102 b, 102 c, 102 d may be configuredto transmit and/or receive wireless signals and may include userequipment (UE), a mobile station, a fixed or mobile subscriber unit, apager, a cellular telephone, a personal digital assistant (PDA), asmartphone, a laptop, a netbook, a personal computer, a wireless sensor,consumer electronics, and the like.

The communication systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106, the Internet 110,and/or the networks 112. By way of example, the base stations 114 a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a HomeNode B, a Home eNode B, a site controller, an access point (AP), awireless router, and the like. While the base stations 114 a, 114 b areeach depicted as a single element, it will be appreciated that the basestations 114 a, 114 b may include any number of interconnected basestations and/or network elements.

The base station 114 a may be part of the RAN 104, which may alsoinclude other base stations and/or network elements (not shown), such asa base station controller (BSC), a radio network controller (RNC), relaynodes, etc. The base station 114 a and/or the base station 114 b may beconfigured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 114 a may be divided intothree sectors. Thus, in one embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 114 a may employ multiple-inputmultiple output (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 116, which may beany suitable wireless communication link (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Theair interface 116 may be established using any suitable radio accesstechnology (RAT).

More specifically, as noted above, the communication system 100 may be amultiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 104 and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Universal MobileTelecommunication System (UMTS) Terrestrial Radio Access (UTRA), whichmay establish the air interface 116 using wideband CDMA (WCDMA). WCDMAmay include communication protocols such as High-Speed Packet Access(HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed DownlinkPacket Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114 a and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (E-UTRA), which may establish the air interface116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a, 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000,CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), InterimStandard 95 (IS-95), Interim Standard 856 (IS-856), Global System forMobile communications (GSM), Enhanced Data rates for GSM Evolution(EDGE), GSM EDGE (GERAN), and the like.

The base station 114 b in FIG. 1A may be a wireless router, Home Node B,Home eNode B, or access point, for example, and may utilize any suitableRAT for facilitating wireless connectivity in a localized area, such asa place of business, a home, a vehicle, a campus, and the like. In oneembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayimplement a radio technology such as IEEE 802.11 to establish a wirelesslocal area network (WLAN). In another embodiment, the base station 114 band the WTRUs 102 c, 102 d may implement a radio technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yetanother embodiment, the base station 114 b and the WTRUs 102 c, 102 dmay utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE,LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A,the base station 114 b may have a direct connection to the Internet 110.Thus, the base station 114 b may not be required to access the Internet110 via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe any type of network configured to provide voice, data, applications,and/or voice over internet protocol (VoIP) services to one or more ofthe WTRUs 102 a, 102 b, 102 c, 102 d. For example, the core network 106may provide call control, billing services, mobile location-basedservices, pre-paid calling, Internet connectivity, video distribution,etc., and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 1A, it will be appreciatedthat the RAN 104 and/or the core network 106 may be in direct orindirect communication with other RANs that employ the same RAT as theRAN 104 or a different RAT. For example, in addition to being connectedto the RAN 104, which may be utilizing an E-UTRA radio technology, thecore network 106 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102 a,102 b, 102 c, 102 d to access the PSTN 108, the Internet 110, and/orother networks 112. The PSTN 108 may include circuit-switched telephonenetworks that provide plain old telephone service (POTS). The Internet110 may include a global system of interconnected computer networks anddevices that use common communication protocols, such as thetransmission control protocol (TCP), user datagram protocol (UDP) andthe internet protocol (IP) in the TCP/IP internet protocol suite. Thenetworks 112 may include wired or wireless communications networks ownedand/or operated by other service providers. For example, the networks112 may include another core network connected to one or more RANs,which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in the communicationsystem 100 may include multi-mode capabilities, i.e., the WTRUs 102 a,102 b, 102 c, 102 d may include multiple transceivers for communicatingwith different wireless networks over different wireless links. Forexample, the WTRU 102 c shown in FIG. 1A may be configured tocommunicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 1B is a system diagram of a representative WTRU 102. As shown inFIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element 122, a speaker/microphone 124, a keypad 126, adisplay/touchpad 128, non-removable memory 130, removable memory 132, apower source 134, a global positioning system (GPS) chipset 136, andother peripherals 138. It will be appreciated that the WTRU 102 mayinclude any sub-combination of the foregoing elements while remainingconsistent with an embodiment.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 118 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the WTRU 102 to operate in a wirelessenvironment. The processor 118 may be coupled to the transceiver 120,which may be coupled to the transmit/receive element 122. While FIG. 1Bdepicts the processor 118 and the transceiver 120 as separatecomponents, it will be appreciated that the processor 118 and thetransceiver 120 may be integrated together in an electronic package orchip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. In another embodiment, the transmit/receiveelement 122 may be an emitter/detector configured to transmit and/orreceive IR, UV, or visible light signals, for example. In yet anotherembodiment, the transmit/receive element 122 may be configured totransmit and receive both RF and light signals. It will be appreciatedthat the transmit/receive element 122 may be configured to transmitand/or receive any combination of wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 1B as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 102 mayinclude two or more transmit/receive elements 122 (e.g., multipleantennas) for transmitting and receiving wireless signals over the airinterface 116.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 130 and/or the removable memory 132.The non-removable memory 130 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that is not physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from abase station (e.g., base stations 114 a, 114 b) and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. It will be appreciated that the WTRU 102 mayacquire location information by way of any suitablelocation-determination method while remaining consistent with anembodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality, and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 1C is a system diagram of the RAN 104 and the core network 106according to an embodiment. As noted above, the RAN 104 may employ aUTRA radio technology to communicate with the WTRUs 102 a, 102 b, and102 c over the air interface 116. The RAN 104 may also be incommunication with the core network 106. As shown in FIG. 1C, the RAN104 may include Node-Bs 140 a, 140 b, 140 c, which may each include oneor more transceivers for communicating with the WTRUs 102 a, 102 b, 102c over the air interface 116. The Node-Bs 140 a, 140 b, 140 c may eachbe associated with a particular cell (not shown) within the RAN 104. TheRAN 104 may also include RNCs 142 a, 142 b. It will be appreciated thatthe RAN 104 may include any number of Node-Bs and RNCs while remainingconsistent with an embodiment.

As shown in FIG. 1C, the Node-Bs 140 a, 140 b may be in communicationwith the RNC 142 a. Additionally, the Node-B 140 c may be incommunication with the RNC142 b. The Node-Bs 140 a, 140 b, 140 c maycommunicate with the respective RNCs 142 a, 142 b via an lub interface.The RNCs 142 a, 142 b may be in communication with one another via anlur interface. Each of the RNCs 142 a, 142 b may be configured tocontrol the respective Node-Bs 140 a, 140 b, 140 c to which it isconnected. In addition, each of the RNCs 142 a, 142 b may be configuredto carry out or support other functionality, such as outer loop powercontrol, load control, admission control, packet scheduling, handovercontrol, macrodiversity, security functions, data encryption, and thelike.

The core network 106 shown in FIG. 1C may include a media gateway (MGW)144, a mobile switching center (MSC) 146, a serving GPRS support node(SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each ofthe foregoing elements are depicted as part of the core network 106, itwill be appreciated that any one of these elements may be owned and/oroperated by an entity other than the core network operator.

The RNC 142 a in the RAN 104 may be connected to the MSC 146 in the corenetwork 106 via an luCS interface. The MSC 146 may be connected to theMGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a, 102 b, and 102 c andtraditional land-line communications devices.

The RNC 142 a in the RAN 104 may also be connected to the SGSN 148 inthe core network 106 via an luPS interface. The SGSN 148 may beconnected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide theWTRUs 102 a, 102 b, 102 c with access to packet-switched networks, suchas the Internet 110, to facilitate communications between and the WTRUs102 a, 102 b, 102 c and IP-enabled devices.

As noted above, the core network 106 may also be connected to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

FIG. 1D is a system diagram of the RAN 104 and the core network 106according to another embodiment. As noted above, the RAN 104 may employan E-UTRA radio technology to communicate with the WTRUs 102 a, 102 b,and 102 c over the air interface 116. The RAN 104 may also be incommunication with the core network 106.

The RAN 104 may include eNode-Bs 160 a, 160 b, 160 c, though it will beappreciated that the RAN 104 may include any number of eNode-Bs whileremaining consistent with an embodiment. The eNode-Bs 160 a, 160 b, 160c may each include one or more transceivers for communicating with theWTRUs 102 a, 102 b, 102 c over the air interface 116. In one embodiment,the eNode-Bs 160 a, 160 b, 160 c may implement MIMO technology. Thus,the eNode-B 160 a, for example, may use multiple antennas to transmitwireless signals to, and receive wireless signals from, the WTRU 102 a.

Each of the eNode-Bs 160 a, 160 b, and 160 c may be associated with aparticular cell (not shown) and may be configured to handle radioresource management decisions, handover decisions, scheduling of usersin the uplink and/or downlink, and the like. As shown in FIG. 1D, theeNode-Bs 160 a, 160 b, 160 c may communicate with one another over an X2interface.

The core network 106 shown in FIG. 1D may include a mobility managementgateway (MME) 162, a serving gateway (SGW) 164, and a packet datanetwork (PDN) gateway (PGW) 166. While each of the foregoing elementsare depicted as part of the core network 106, it will be appreciatedthat any one of these elements may be owned and/or operated by an entityother than the core network operator.

The MME 162 may be connected to each of the eNode-Bs 160 a, 160 b, and160 c in the RAN 104 via an S1 interface and may serve as a controlnode. For example, the MME 162 may be responsible for authenticatingusers of the WTRUs 102 a, 102 b, 102 c, bearer activation/deactivation,selecting a particular serving gateway during an initial attach of theWTRUs 102 a, 102 b, 102 c, and the like. The MME 162 may also provide acontrol plane function for switching between the RAN 104 and other RANs(not shown) that employ other radio technologies, such as GSM or WCDMA.

The serving gateway 164 may be connected to each of the eNode Bs 160 a,160 b, 160 c in the RAN 104 via the S1 interface. The serving gateway164 may generally route and forward user data packets to/from the WTRUs102 a, 102 b, 102 c. The serving gateway 164 may also perform otherfunctions, such as anchoring user planes during inter-eNode B handovers,triggering paging when downlink data is available for the WTRUs 102 a,102 b, 102 c, managing and storing contexts of the WTRUs 102 a, 102 b,102 c, and the like.

The serving gateway 164 may also be connected to the PDN gateway 166,which may provide the WTRUs 102 a, 102 b, 102 c with access topacket-switched networks, such as the Internet 110, to facilitatecommunications between the WTRUs 102 a, 102 b, and 102 c and IP-enableddevices.

The core network 106 may facilitate communications with other networks.For example, the core network 106 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a, 102 b, and 102 c andtraditional land-line communications devices. For example, the corenetwork 106 may include, or may communicate with, an IP gateway (e.g.,an IP multimedia subsystem (IMS) server) that serves as an interfacebetween the core network 106 and the PSTN 108. In addition, the corenetwork 106 may provide the WTRUs 102 a, 102 b, 102 c with access to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

FIG. 1E is a system diagram of the RAN 104 and the core network 106according to another embodiment. The RAN 104 may be an access servicenetwork (ASN) that employs IEEE 802.16 radio technology to communicatewith the WTRUs 102 a, 102 b, and 102 c over the air interface 116. Aswill be further discussed below, the communication links between thedifferent functional entities of the WTRUs 102 a, 102 b, 102 c, the RAN104, and the core network 106 may be defined as reference points.

As shown in FIG. 1E, the RAN 104 may include base stations 170 a, 170 b,170 c, and an ASN gateway 172, though it will be appreciated that theRAN 104 may include any number of base stations and ASN gateways whileremaining consistent with an embodiment. The base stations 170 a, 170 b,170 c may each be associated with a particular cell (not shown) in theRAN 104 and may each include one or more transceivers for communicatingwith the WTRUs 102 a, 102 b, 102 c over the air interface 116. In oneembodiment, the base stations 170 a, 170 b, 170 c may implement MIMOtechnology. Thus, the base station 170 a, for example, may use multipleantennas to transmit wireless signals to, and receive wireless signalsfrom, the WTRU 102 a. The base stations 170 a, 170 b, 170 c may alsoprovide mobility management functions, such as handoff triggering,tunnel establishment, radio resource management, traffic classification,quality of service (QoS) policy enforcement, and the like. The ASNgateway 172 may serve as a traffic aggregation point and may beresponsible for paging, caching of subscriber profiles, routing to thecore network 106, and the like.

The air interface 116 between the WTRUs 102 a, 102 b, 102 c and the RAN104 may be defined as an R1 reference point that implements the IEEE802.16 specification. In addition, each of the WTRUs 102 a, 102 b, and102 c may establish a logical interface (not shown) with the corenetwork 106. The logical interface between the WTRUs 102 a, 102 b, 102 cand the core network 106 may be defined as an R2 reference point, whichmay be used for authentication, authorization, IP host configurationmanagement, and/or mobility management.

The communication link between each of the base stations 170 a, 170 b,and 170 c may be defined as an R8 reference point that includesprotocols for facilitating WTRU handovers and the transfer of databetween base stations. The communication link between the base stations170 a, 170 b, 170 c and the ASN gateway 172 may be defined as an R6reference point. The R6 reference point may include protocols forfacilitating mobility management based on mobility events associatedwith each of the WTRUs 102 a, 102 b, 100 c.

As shown in FIG. 1E, the RAN 104 may be connected to the core network106. The communication link between the RAN 104 and the core network 106may defined as an R3 reference point that includes protocols forfacilitating data transfer and mobility management capabilities, forexample. The core network 106 may include a mobile IP home agent(MIP-HA) 174, an authentication, authorization, accounting (AAA) server176, and a gateway 178. While each of the foregoing elements aredepicted as part of the core network 106, it will be appreciated thatany one of these elements may be owned and/or operated by an entityother than the core network operator.

The MIP-HA 174 may be responsible for IP address management, and mayenable the WTRUs 102 a, 102 b, and 102 c to roam between different ASNsand/or different core networks. The MIP-HA 174 may provide the WTRUs 102a, 102 b, 102 c with access to packet-switched networks, such as theInternet 110, to facilitate communications between the WTRUs 102 a, 102b, and 102 c and IP-enabled devices. The AAA server 176 may beresponsible for user authentication and for supporting user services.The gateway 178 may facilitate interworking with other networks. Forexample, the gateway 178 may provide the WTRUs 102 a, 102 b, 102 c withaccess to circuit-switched networks, such as the PSTN 108, to facilitatecommunications between the WTRUs 102 a, 102 b, and 102 c and traditionalland-line communications devices. In addition, the gateway 178 mayprovide the WTRUs 102 a, 102 b, 102 c with access to the networks 112,which may include other wired or wireless networks that are owned and/oroperated by other service providers.

Although not shown in FIG. 1E, it will be appreciated that the RAN 104may be connected to other ASNs and the core network 106 may be connectedto other core networks. The communication link between the RAN 104 theother ASNs may be defined as an R4 reference point, which may includeprotocols for coordinating the mobility of the WTRUs 102 a, 102 b, 102 cbetween the RAN 104 and the other ASNs. The communication link betweenthe core network 106 and the other core networks may be defined as an R5reference, which may include protocols for facilitating interworkingbetween home core networks and visited core networks.

A mobile user may choose from a wide range of technologies to accessnetworks such as GPRS, EDGE, 3G and/or 4G for wide area access, and/orWiFi for local area access. Mobile hosts are increasingly becomingmulti-homed (e.g., connected via multiple access technologies and/ormulti-access points) and may possess two or more heterogeneousinterfaces. Internet content is being increasingly distributed (e.g.,over a “cloud”) such that content delivery is becoming more complex(e.g., to get the right content from the right location).

In certain representative embodiments, a multi-homed wireless device(e.g., a mobile host, mobile device, netbook and/or WTRU 102, amongothers) may access or receive (e.g., efficiently access or receive)content (e.g., internet-based content).

In certain representative embodiments, a multi-homed mobile host may use(e.g., may fully utilize) a subset or all of the available interfaces(e.g., wireless and/or wired) to send content or to receive content(e.g., efficiently receive content).

Although the receiver is described in FIGS. 1A-1E as a wirelessterminal, it is contemplated that in certain representative embodimentsthat such a terminal may use wired communication interfaces with thecommunication network.

FIG. 2 is a diagram illustrating a representative communication system200 similar to that of FIG. 1D in which the L-GW may be collocated withthe Home evolved NodeB (HeNB).

Referring to FIG. 2, the representative communication system 200 mayinclude an Evolved Packet Core (EPC) 210 (e.g., 3GPP Evolved PacketCore), an IP backhaul 220 and/or a home network 230, among others. TheEPC 210 may include a PGW 212, an SGW 214 and a MME 216. The homenetwork may include a local gateway LGW 232 and a Home eNB 234. ASecurity Gateway (SeGW) may provide security and/or authenticationfunctions between the EPC 210 and, for example, home network 230. A homerouter (HR) and/or network address translator (NAT) HR/NAT 250 may actor operate as a router for packets traversing to or from the LGW 232and/or HeNB 234. The HR/NAT 250, for example, may hide the IP addressspace of the home network (e.g., private IP addresses) behind a singleIP address (or a group of IP addresses) and may include a NetworkAddress Table for routing IP packets to the private IP addresses of theLGW 232 and/or HeNB 234.

The SeGW 260 may act or operate as a first endpoint (e.g., correspondingto a first IP address) of a tunnel 270 and the home network (e.g., theHR/NAT 250 or other device in the home network 230) may act or operateas a second endpoint (e.g., corresponding to a second IP address) of thetunnel 270. The WTRU 102 may communicate (e.g., wirelessly communicate)with the HeNB 234.

The PGW 212 may be coupled (e.g., connected) via an S5 interface to theSGW 214 and the SGW 214 may be coupled (e.g., connected) via an S11interface to the MME 216. The MME 216 of the EPC 210 may couple (e.g.,connect) with the HeNB 234 via a S1-mme interface via the SeGW 260 andHR/NAT 250. The SGW 214 of the EPC 210 may couple (e.g., connect) withthe HeNB 234 via a S1-U interface via the SeGW 260 and HR/NAT 250 andmay couple (e.g., connect) with the LGW 232 via a S5 interface via theSeGW 260 and HR/NAT 250.

In certain representative embodiments, a MRA connection setup may beused in which an Access Point (AP) (e.g., a HNB or a HeNB, among others)may be selected for the MRA and data may go (e.g., traverse) via theselected AP.

In certain representative embodiments, the procedure may setup thecontext at the AP (e.g., a HNB or HeNB) such that no radio resource maybe active and resources (e.g., only resources) towards the SGW 214 andthe LGW 232 may be active.

In certain representative embodiments, a handover (HO) may be initiatedbetween a MRA and a LIPA in either direction based on the movement ofthe WTRU 102. For the LIPA to the MRA, after the HO, radio resources(e.g., only radio resources) may be released at the source AP (e.g., theHNB or the HeNB) while resources with the LGW 232 and the SGW 214 may bemaintained. The data path for MRA may be changed to go (e.g., traverse)via the SGW 214. Representative examples of triggers that may be used toinitiate the change may include: (1) idle mode mobility, which may havedifferent handling of MRA/LIPA transitions based on whether the WTRU 102is performing signaling procedure or procedures associated with userdata; and/or (2) MRA access checks, among others.

Access to a local IP network may be achieved by the use of the LGW thatmay have similar functions to those of a PGW (or GGSN).

Although HeNBs are used herein to describe APs, other access pointtechnologies may be used such as HNB (UTRAN), for example. The termsH(e)NB, HeNB or HNB may be interchangeable through the specification andmay define a Home Node B and/or a Home eNode B.

The LGW 232 may be collocated at or with the HeNB 234. Since the LGW 232may be collocated with the HeNB 234, if a WTRU 102 moves out of thecoverage of the HeNB 234 (e.g., in either idle or connected mode) theLIPA connection may be deactivated. For a WTRU 102 in connected mode,which is about to perform handover (HO) to another cell, the HeNB 232may first inform the LGW 232 about the HO so that the latter deactivatesthe LIPA PDN connection. After (e.g., only after) the LIPA PDNconnection is deactivated, may the WTRU 102 be handed over to anothercell. During the HO, if the MME 216 determines that the LIPA bearer/PDNconnection is no deactivated, the MME 216 may reject the HO.

FIG. 3 is a diagram illustrating another representative communicationsystem 300 including a plurality of LGWs 332, each with respective HeNBs334. FIG. 4 is a diagram illustrating a portion of the representativecommunication system of FIG. 3 with a WTRU 102 moving and connecting to(e.g., accessing the system via) different respective HeNBs 334 along amovement pat (e.g., the WTRU 102 may move between different HeNBsconnected to same L-GW).

Referring to FIG. 3, a representative communication system 300 mayinclude a plurality of Pack Data Networks 310A and 310B and a pluralityof local HeNB networks 320A and 320B connected to the plurality ofPacket Data Networks 310A and 310B via interfaces. Local HeNB network320A may include LGW 332A and one or more HeNBs 334A, 334B and 334Ccoupled (e.g., connected) to the LGW 332A. Local HeNB network 320B mayinclude LGW 332B and one or more HeNBs 334D and 334E coupled (e.g.,connected) to the LGW 332B.

Referring to FIG. 4, the WTRU 102 may move between HeNBs 334A, 334B and334C along a movement path denoted by the arrows. To allow continuity ofa LIPA PDN connection 350 as the WTRU 102 moves between HeNBs 334A, 334Band 334C of Local HeNB network 320A, the LGW 332A may be remote orseparated from the HeNBs 334A, 334B and 334C. Multiple HeNBs may connectto the same LGW such that the WTRU 102 with a LIPA PDN connection 350may move across these HeNBs (referred to as HeNB subsystem) 334 whilemaintaining its LIPA PDN connection 350.

It is contemplated that, if a WTRU 102 moves out of the HeNB subsystem334 altogether (e.g., moves out of coverage of all the HeNBs 334A, 334Band 334C that connect to a LGW 332A), the WTRU's PDN connection 350 forLIPA may be deactivated.

FIG. 5 is a diagram illustrating Selected IP Traffic Offload (SIPTO)using a representative communication system 500.

Referring to FIG. 5, the representative communication system 500 mayinclude a core network (CN) 510 and a radio access network (RAN) 520.The CN 510 may include an MME 512 and a PGW 514. The RAN 520 may includean AP 522 (e.g., an eNB or other AP). A SGW 530 and a local PGW (L-PGW)540 may be located at the RAN 520 (e.g., local to the RAN 520 oroperationally before the CN 510. The WTRU 102 may communicate with theAP 522.

The PGW 514 may be coupled (e.g., connected) via an S5 interface to theSGW 530 and the MME 512 may be coupled (e.g., connected) via an S11interface to the SGW 530. The SGW 530 may be coupled (e.g., connect) tothe AP 522 via a S1-U interface and may be coupled (e.g., connect) withthe L-PGW 540 via the S5 interface.

Selected IP Traffic Offload (SIPTO) generally refers to an offload inwhich a network operator chooses a PGW to offload traffic to theInternet such that the WTRU's physical location or IP topologicallocation makes it favorable to select a PGW (e.g., L-PGW 540) differentfrom the PGW 514 of the CN 510. SIPTO may be achieved above (e.g., orexternal to) the RAN 520 and regardless of whether the radio connectionof the WTRU 102 is obtained via the AP 522 (e.g., an eNB, a HeNB or anyother AP). The selection of another PGW may not be known to the WTRU102, and the offload of the traffic of the WTRU 102 to the L-PGW 540 maydegrade the user's service experience. Two traffic streams are shown inFIG. 5, a SIPTO traffic stream 560 that may be routed through the SGW530 to the L-PGW 540, and a CN traffic stream 570 that may be routedthrough the SGW 530 to the PGW 514 in the CN 510.

The eNB 522 may be a HeNB configured to perform SIPTO in a home networkof the user of the WTRU 102 and traffic may be offloaded locally to auser's home network. The home network may be an IP network that isconnected to other devices such as a printer, a television, and/or apersonal computer, among others.

SIPTO may include single or multiple packet data network (PDN)connections, and/or deployment behind network address translation (NAT),among others.

For traffic going through the mobile operator's core network, the SGW530 user plane functions may be located within the CN 510. Mobilitymanagement signaling between the WTRU 102 and the network may be handledin the CN 510. Session management signaling, such as bearer setup, forSIPTO traffic, and traffic going through the CN 510 may terminate in theCN 510. Reselection of a WTRU's offload point for SIPTO traffic that isgeographically or topologically close to the WTRU 102 may be possibleduring idle mode mobility procedures.

The representative system 500 may include the L-PGW 540 that is close toa WTRU's point of attachment to the RAN 520. The L-PGW 560 may performIP traffic 560 offload based on some policy or configuration, forexample, based on the IP address destination and/or services requested(e.g., video and/or streaming services), among others. IP traffic 560may go through the L-PGW 540 rather than through the operator's CN 510(via for example, the SGW 530 and the PGW 514 or via an SGSN and a GGSN(not shown).

The L-PGW 540 may have certain functionalities of a PDW/GGSN. Forexample, the L-PGW 540 may include functionalities such as: (1) IPaddress allocation; (2) direct tunneling with the RAN 520 in connectedmode, (3) per WTRU policy based packet filtering; and/or (4) ratepolicing/shaping. A PDN connection (e.g., a proper PDN connection) maybe used to perform SIPTO and/or LIPA transfers to a LN or the Intranet,The WTRU 102 may set an access point name (APN) to a specific value whenrequesting a PDN connection or when requesting the establishment of apacket data protocol (PDP) context.

FIG. 6 is a diagram illustrating a representative communication system600 configured for user data offload to the Internet via a LGW that maybe connected to a HeNB subsystem.

As shown in FIG. 6, the representative communication system 600 mayinclude a mobile operator network 610, an enterprise network 620 and aLTE macro network 630. The mobile operator network 610 may include anMME 612, a PGW 614 and a SGW 616. The enterprise network 620 may includea LGW 622, a HeNB subsystem 624 (e.g., including a plurality of HeNBs624A, 624B and 624C). The LTE macro network 630 may include, forexample, one or more eNBs 632.

The PGW 614 may be coupled (e.g., connected) via an S5 interface to theSGW 616 and the SGW 616 may be coupled (e.g., connected) via S1-Uinterfaces to the APs of the enterprise network 602 and/or of the LTEmacro network 630 (e.g., the HeNBs 624A, 624B, 624C and/or eNB 632,among others). The MME 612 may be coupled (e.g., connected) with the APsof the enterprise network 620 and/or of the LTE macro network 630 (e.g.,the HeNBs 624A, 624B, 624C and/or eNB 632, among others) via S1-MMEinterfaces. The LGW 622 may be coupled (e.g., connected) with the HeNBs624A, 624B, 624C of the HeNBs subsystem 624 via other interfaces.

The WTRU 102 may communicate with one of the HeNBs 624B of the HeNBsubsystem 624 and may handover to the HeNB 624C of the HeNB subsystem624 based on one or more criteria including: (1) the movement of theWTRU 102; (2) the signal strength of the communication with the HeNBs624B and 624C; (3) loading of the HeNB 624B; (4) capabilities of theWTRU 102 and/or HeNB 624B and 624C; and/or (5) services requested by theWTRU 102, among others.

The offload of user data to the Internet may be provided via the LGW 622that is coupled or connected to the HeNB subsystem 624. In thisrepresentative system 600 (e.g., architecture), local IP network (LIPA)and/or SIPTO may be used (e.g., the LGW 622 may be used to access theLIPA, while also being able to offload a WTRU's data to the Internet viathe same LGW 622. The system/architecture may enable both LIPA mobilityand SIPTO service continuity.

In certain representative embodiments, a PDN connection via a HeNB 624Bof a HeNB subsystem 624 may be established to perform LIPA transfersbetween the WTRU 102 and the Intranet. If a handover of the HeNB occursto another HeNB 624C of the HeNB subsystem 624, the PDN connection maybe moved, transferred and/or reestablished with the HeNB 624C tocontinue/reestablish the PDN connection.

Stand-Alone Logical LGW

FIG. 7 is a diagram illustrating a representative standalone LGWarchitecture 700 for a HeNB subsystem in which the HeNB 710 mayinterface with the HeNB GW 720 via the S1-U interface.

Referring to FIG. 7, the representative standalone LGW architecture 700may include one or more HeNBs 710 (collectively the HeNB subsystem notshown), a HeNB Gateway 720 a LGW 730, a SGW 740, an MME 750, a SeGW 760and/or a WTRU 102.

The LGW 730 may be coupled to (e.g., connected to): (1) a packet datanetwork (PDN) or internet via a SGi interface; (2) the one or more HeNBs710 via an Sxx interface; and/or (3) the SGW 740 via an S5 interface.The SGW 740 may be coupled to (e.g., connected to): (1) the LGW via theS5 interface; (2) the one or more HeNBs 710 via an S1U interface; and/or(3) the MME 750 via an S11 interface. The MME 750 may be coupled to(e.g., connected to): (1) the SGW 740 via the S11 interface; and/or (2)the one or more HeNBs 710 via an S1-MME interface. The one or more HeNBs710 may be coupled to (e.g., connected to): (1) the LGW 730 via the Sxxinterface; (2) the SGW 740 via the S1-U interface; (3) the WTRU 102 viaa Uu interface; and/or (4) the MME 750 via the S1-MME interface. EachHeNB 710 of the HeNB subsystem may be coupled to (e.g., connected to)other HeNBs 710 of the HeNB subsystem via an X2 interface.

In certain representative embodiments, the HeNB GW 720 may be included:(1) in the pathway of the S1-MME interface between the MME 750 and theHeNBs 710; and/or (2) in the pathway of the S1-U interface between theSGW 740 and the HeNBs 710.

In certain representative embodiments, the SeGW 760 may be included: (1)in the pathway of the S5 interface between the LGW 730 and the SGW 740;(2) in the pathway of the S1-U interface between the SGW 740 and theHeNBs 710; and/or (3) in the pathway of the S1-MME interface between theMME 750 and the HeNBs 710.

FIG. 8 is a diagram illustrating another representative standalone LGWarchitecture 800 for an HNB subsystem in which the HNB may interfacewith the HNB GW via the luh interface for an Evolved Packet System(EPS).

Referring to FIG. 8, the representative architecture 800 may include oneor more home NodeBs (HNBs) 810 (collectively the HNB subsystem, notshown), a HNB Gateway 820 a LGW 830, a SGW 840, an S4-SGSN 850, a SeGW860 and/or a WTRU 102.

The LGW 830 may be coupled to (e.g., connected to): (1) a PDN orinternet via a SGi interface; (2) the one or more HNBs 810 via an Sxxinterface; and/or (3) the SGW 840 via an S5 interface. The SGW 840 maybe coupled to (e.g., connected to): (1) the LGW 830 via the S5interface; (2) the HNB GW 820 via a lu-UP interface; and/or (3) the S4SGSN 850 via an S4 interface. The S4-SGSN 850 may be coupled to (e.g.,connected to): (1) the SGW 840 via the S4 interface; and/or (2) the HNBGW 820 via a lu-CP interface. The one or more HNBs 810 may be coupled to(e.g., connected to): (1) the LGW 830 via the Sxx interface; (2) the HNBGW 820 via a luh interface; and/or (3) the WTRU 102 via a Uu interface.Each HNB 810 of the HNB subsystem may be coupled to (e.g., connected to)other HNBs 810 of the HNB subsystem via a lurh interface. The HNB GW 820may be coupled to (e.g., connected to): (1) the HNBs 810 via the luhinterface; (2) the SGW 840 via a lu-UP interface and/or (3) the S4-SGSN850 via the lu-CP interface.

In certain representative embodiments, the SeGW 860 may be included: (1)in the pathway of the S5 interface between the LGW 830 and the SGW 840;and/or (2) in the pathway of the luh interface between the HNB GW 820and the HNBs 810.

FIG. 9 is a diagram illustrating a further representative standalone LGWarchitecture 900 for an HNB subsystem in which the HNB 910 may interfacewith the HNB GW 920 via the luh interface for a Universal MobileTelecommunications System (UMTS).

Referring to FIG. 9, the representative architecture 900 may include oneor more home NodeBs (HNBs) 910 (collectively the HNB subsystem notshown), a HNB Gateway 920 a LGW 930, a SGSN 950, a SeGW 960 and/or aWTRU 102.

The LGW 930 may be coupled to (e.g., connected to): (1) a PDN or theInternet via a Gi interface; (2) the one or more HNBs 910 via an Sxxinterface; and/or (3) the SGSN 950 via a Gn interface. The SGSN 850 maybe coupled to (e.g., connected to): (1) the LGW 930 via the Gninterface; and/or (2) the HNB GW 920 via a lu interface. The one or moreHNBs 910 may be coupled to (e.g., connected to): (1) the LGW 930 via theSxx interface; (2) the HNB GW 920 via the luh interface; and/or (3) theWTRU 102 via a Uu interface. Each HNB 910 of the HNB subsystem may becoupled to (e.g., connected to) other HNBs 910 of the HNB subsystem viaa lurh interface. The HNB GW 920 may be coupled to (e.g., connected to):(1) the HNBs 910 via the luh interface; and/or (2) the SGSN 950 via thelu interface.

In certain representative embodiments, the SeGW 960 may be included: (1)in the pathway of the Gn interface between the LGW 930 and the SGSN 950;and/or (2) in the pathway of the luh interface between the HNB GW 920and the HNBs 910.

FIG. 10 is a diagram illustrating an additional representativestandalone LGW architecture 1000 for a HeNB subsystem in which the HeNB1010 may interface with the HeNB GW 1020 via the S1-U interface and theLGW 1030 is on the S1 path.

Referring to FIG. 10, the representative architecture 1000 may includeone or more HeNBs 1010 (collectively the HeNB subsystem, not shown), aHeNB Gateway 1020, a LGW 1030, a SGW 1040, an MME 1050, a SeGW 1060and/or a WTRU 102.

The LGW 1030 may be coupled to (e.g., connected to): (1) a PDN or theInternet via a SGi interface; (2) the one or more HeNBs 1010 via an S1-Uinterface and/or the S1-MME interface; (3) the MME 1050 via the S1-MMEinterface; (4) the SGW 1040 via the S1-U interface; and/or (5) the SGW740 via an S5 interface. For example, the LGW 1030 may be disposed inthe path of the S1U interface and/or S1-MME interface.

The SGW 1040 may be coupled to (e.g., connected to): (1) the LGW 1030via the S5 interface; (2) the one or more HeNBs 1010 via an S1-Uinterface through the LGW 1030; and/or (3) the MME 1050 via an S11interface. The MME 1050 may be coupled to (e.g., connected to): (1) theSGW 1040 via the S11 interface; and/or (2) the one or more HeNBs 1010via an S1-MME interface through the LGW 1030. The one or more HeNBs 1010may be coupled to (e.g., connected to): (1) the SGW 1040 via the S1-Uinterface through the LGW 1030; (2) the MME 1050 via the S1-MMEinterface through the LGW 1030; and/or (3) the WTRU 102 via a Uuinterface. Each HeNB 1010 of the HeNB subsystem may be coupled to (e.g.,connected to) other HeNBs 1010 of the HeNB subsystem via an X2interface.

In certain representative embodiments, the HeNB GW 1020 may be included:(1) in the pathway of the S1-MME interface between the MME 1050 and theLGW 1030; and/or (2) in the pathway of the S1-U interface between theSGW 1040 and the LGW 1030.

In certain representative embodiments, the SeGW 1060 may be included:(1) in the pathway of the S5 interface between the LGW 1030 and the SGW1040; (2) in the pathway of the S1-U interface between the SGW 1040 andthe LGW 1030; and/or (3) in the pathway of the S1-MME interface betweenthe MME 1050 and the LGW 1030.

FIG. 11 is a diagram illustrating a representative standalone LGWarchitecture 1100 for an HNB subsystem in which the HNB 1110 mayinterface with the HNB GW 1120 via the luh interface for an EvolvedPacket System (EPS) and the LGW 1130 is on the luh path.

Referring to FIG. 11, the representative architecture 1100 may includeone or more home NodeBs (HNBs) 1110 (collectively the HNB subsystem, notshown), a HNB Gateway 1120, a LGW 1130, a SGW 1140, an S4-SGSN 1150, aSeGW 1160 and/or a WTRU 102.

The LGW 1130 may be coupled to (e.g., connected to): (1) a PDN or theInternet via a SGi interface; (2) the one or more HNBs 1110 via a luh;(3) the HNB GW 1120 via the luh interface; and/or (4) the SGW 1140 viaan S5 interface. For example, the LGW 1130 may be disposed in the pathof the luh interface.

The SGW 1140 may be coupled to (e.g., connected to): (1) the LGW 1130via the S5 interface; (2) the HNB GW 1120 via a lu-UP interface; and/or(3) the S4-SGSN 1150 via an S4 interface. The S4-SGSN 1150 may becoupled to (e.g., connected to): (1) the SGW 1140 via the S4 interface;and/or (2) the HNB GW 1120 via the lu-CP interface. The one or more HNBs1110 may be coupled to (e.g., connected to): (1) the HNB GW 1120 via theluh interface through the LGW 1130; and/or (2) the WTRU 102 via the Uuinterface. Each HNB 1110 of the HNB subsystem may be coupled to (e.g.,connected to) other HNBs 1110 of the HNB subsystem via a lurh interface.

In certain representative embodiments, the SeGW 1160 may be included:(1) in the pathway of the S5 interface between the LGW 1130 and the SGW1140; and/or (2) in the pathway of the luh interface between the HNB GW1120 and the LGW 1130.

FIG. 12 is a diagram illustrating a standalone representative LGWarchitecture 1200 for an HNB subsystem in which the HNB 1210 mayinterface with the HNB GW 1220 via the luh interface for a UniversalMobile Telecommunications System (UMTS) and the LGW 1230 is on the luhpath.

Referring to FIG. 12, the architecture 1200 may include one or more homeNodeBs (HNBs) 1210 (collectively the HNB subsystem not shown), a HNBGateway 1220 a LGW 1230, a SGSN 1250, a SeGW 1260 and/or a WTRU 102.

The LGW 1230 may be coupled to (e.g., connected to): (1) a PDN orinternet via a Gi interface; (2) the one or more HNBs 1210 via a luh;(3) the HNB GW 1220 via the luh interface; and/or (4) the SGSN 1250 viaa Gn interface. For example, the LGW 1230 may be disposed in the path ofthe luh interface.

The SGSN 1250 may be coupled to (e.g., connected to): (1) the LGW 1230via the Gn interface; and/or (2) the HNB GW 1220 via a luh interface.The one or more HNBs 1210 may be coupled to (e.g., connected to): (1)the HNB GW 1220 via the luh interface through the LGW 1230; and/or (2)the WTRU 102 via a Uu interface. Each HNB 1210 of the HNB subsystem maybe coupled to (e.g., connected to) other HNBs 1210 of the HNB subsystemvia a lurh interface. The HNB GW 1220 may be coupled to (e.g., connectedto): (1) the SGSN 1250 via the lu interface; and/or (2) the LGW 1230 viathe luh interface.

In certain representative embodiments, the SeGW 1260 may be included:(1) in the pathway of the Gn interface between the LGW 1230 and the SGSN1250; and/or (2) in the pathway of the luh interface between the HNB GW1220 and the LGW 1230.

Managed remote access (MRA) or Remote LIPA (RIPA generally refers tocontinuity of data sessions as users move between local and macronetwork/coverage. For example, a user might connect to a LN via themacro coverage (e.g., a macro cell, or a HeNB that is not part of a LN).

FIG. 13 is a diagram illustrating a handover procedure including atransition between a LIPA session and a MRA session using an eNB in amacro network.

Referring to FIG. 13, a representative communication system 1300 mayinclude a mobile operator core network 1310, an enterprise network (orLN) 1320 and/or a macro network 1330. The mobile operator core network1310 may include one or more network entities 1312. The macro network1330 may include one or more second APs (e.g., one or more eNBs) 1332.

The enterprise network or LN 1320 may include one or more APs 1322(e.g., a HNB, a HeNB, a HeNB subsystem, and/or an HNB subsystem, amongothers). A WTRU 102 may be positioned in a coverage area of the LN 1320and may be provided a connection via the one or more APs 1322 in the LN1320. The LN 1320 may be configured for user data offload to theInternet or the LN 1320 (e.g., a local IP network via the LN 1320). Theone or more APs 1322 of the LN 1320 may provide coverage to the WTRU 102(e.g., a LIPA session for the WTRU 102 to connect, for example to avideo server 1324 in the LN 1320).

Although a video server 1324 is shown in the LN 1320, it is contemplatedthat the connection may be to any type of server or other networkresource inside of or external to the LN 1320.

In certain representative embodiments, the WTRU 102 may communicate withthe AP 1322 of the LN 1320 and may handover to the second AP 1332 of themacro network 1330 based on one or more criteria including (1) themovement of the WTRU 102; (2) the signal strength of the communicationwith the APs 1322 and 1332; (3) loading of the APs 1322 and 1332; (4)capabilities of the WTRU 102, of the AP 1322 and/or the AP 1332; (5)velocity of the WTRU 102 and/or (5) services requested by the WTRU 102,among others.

When the user (e.g., WTRU 102) moves into the coverage area of a macronetwork 1330, a LIPA session may be continued as a MRA session. Ingeneral, a session is referred to as MRA session when the actual cell(macro or HeNB) does not connect to the LN 1320. For example, a WTRU 102with a LIPA session may move to an eNB 1332 that is not part of the LN1320 and the LIPA session may be continued as a MRA in the target eNB.

In certain representative embodiments, the WTRU 102 may communicate withthe second AP 1332 of the macro network 1330 and may handover to the AP1332 of the macro network 1330 based on, for example the criteria setforth above.

When the user (e.g., WTRU 102) moves into the coverage area of a LN1320, the MRA session may be continued as a LIPA session. In certainrepresentative embodiments, the WTRU 102 may have an MRA session usingthe eNB 1332 that does not connect to the LN 1320, but when the usermoves into the coverage area of the LN 1320 and hands off to the AP 1322of the LN 1320, the MRA session may be continued as a LIPA session.

FIG. 14 is a diagram illustrating a handover procedure including atransition between a LIPA session and a MRA session using a HeNB or HNBin another LN.

Referring to FIG. 14, a representative communication system 1400 mayinclude the mobile operator core network 1410, an enterprise network (orLN) 1420 and/or another LN 1430. The mobile operator core network 1410may include one or more network entities 1412. The enterprise network orLN 1420 may include one or more APs 1422 (e.g., a HNB, a HeNB, a HeNBsubsystem, and/or an HNB subsystem, among others). A WTRU 102 may bepositioned in a coverage area of the LN 1420 and may be provided aconnection via the one or more APs 1422 in the LN 1420. The LN 1420 maybe configured for user data offload to the Internet or the LN 1420(e.g., a local IP network via the LN 1420). The one or more APs 1422 ofthe LN 1420 may provide coverage to the WTRU 102 (e.g., a LIPA sessionfor the WTRU 102 to connect, for example, to a personal computer orother network resource 1424 in the LN 1420 or external to the LN 1420via the Internet). The other LN 1430 may include one or more second APs(e.g., one or more HeNBs or HNBs) 1432.

In certain representative embodiments, the WTRU 102 may communicate withthe AP 1422 of the LN 1420 and may handover to the second AP 1432 of theother LN 1430 based on one or more criteria, for example, as set forthherein.

When the user (e.g., WTRU 102) moves into the coverage area of the otherLN 1430, a LIPA session may be continued as a MRA session. For example,a WTRU 102 with a LIPA session may move to a coverage area of a HeNB1432 of the other LN 1430 that is not part of the LN 1420 and the LIPAsession may be continued as a MRA in the target HeNB or HNB 1432.

In certain representative embodiments, the WTRU 102 may communicate withthe second AP 1432 of the other LN 1430 and may handover to the AP 1422of the LN 1420 based on, for example the criteria set forth herein.

When the user (e.g., WTRU 102) moves into the coverage area of a LN1420, the MRA session may be continued as a LIPA session. In certainrepresentative embodiments, the WTRU 102 may have an MRA session in theHeNB or HNB 1432 that does not connect to the LN 1420, but when the usermoves into the coverage area of the LN 1420 and hands off to the AP 1422of the LN 1420, the MRA session may be continued as a LIPA session.

Although the examples above are related to LIPA, they may apply toSIPTO, as well. For example, SIPTO@LN can occur within a LN or via macrocoverage (or via another LN using a HeNB or HNB) that may not be part ofthe local coverage) as a MRA.

In certain representative embodiments, a continuity procedure may beused when the WTRU remains within the LN and connects to the AP of theLN (for example, when the WTRU is not allowed to have a LIPAsession/service from a particular closed subscriber group (CSG) (e.g.,due to subscription information).

FIG. 15 is a diagram illustrating a representative data path for thedownlink.

Referring to FIG. 15, a representative communication system 1500 mayinclude operator's resources 1510, LN resources 1520, and/or othernetwork resources 1530. The operator's resources 1510 may include, forexample, an SGW 1512 and/or an MME/SGSN 1514. The SGW 1512 and theMME/SGSN 1514 each may be part of the core network or the SGW 1512 maybe located outside of the core network. The LN resources 1520 mayinclude one or more APs (e.g., one or more HeNBs or HNBs). The other LNresources 1530 may include one or more second APs (e.g., one or moreeNBs).

The data path (represented by arrows) for an MRA session may traverse(e.g., go through) the HeNB or HNB 1522. In the downlink, the data pathmay traverse (e.g., go) from a LGW 1540 to the HeNB or HNB 1522, andfrom the HeNB or HNB 1522 to the network entities or operator's resource1510 (which may be the SGW 1512), and from the operator's resource 1510(e.g., the SGW 1512) to the serving cell, and to the WTRU 102. The datapath may be reversed in the uplink

Radio Access Network (RAN) generally refers to networks having radioaccess points such as eNBs, HeNBs, NBs, and/or HNBs, among others. CoreNetwork (CN) generally refers to different type of networks, forexample, including MME, SGSN, MSC/VLR, and/or SGW, among others.

A WTRU 102 may transition to connected mode (e.g., using radio resourcecontrol (RRC)) to perform a procedure with the CN. When a WTRU 102 sendsa NAS message that is received at the CN, the WTRU 102 may establish aNAS signaling connection. For example, in LTE, a registered WTRU 102 inidle mode (e.g., where RRC and NAS may be idle) may initiate a NASService Request procedure to transition from idle mode to connectedmode. After establishing the RRC connection with the eNB 1532, the WTRU102 may send the NAS Service Request message included with (e.g., piggybacked in) a RRC Connection Setup Complete message (e.g., an RRC messagethat may include the establishment of the RRC connection). The eNB 1532may send the NAS message to the CN over an S1 interface using an InitialWTRU Message. The eNB 1532 may include in the message an identifier thatmay be used by the MME/SGSN 1514 for communicating with the eNB 1532information (e.g., any information) that may be relevant for theconnection. The identifier may be a reference point for a particularWTRU 102 (e.g., for any information that may be sent with reference tothis identifier). The eNB 1532 may map the information to a particularWTRU 102 that is being served. The identifier may be referred to as aneNB WTRU S1AP ID. The contents of the Initial WTRU Message sent by theeNB 1532 to transfer the initial layer 3 message to the MME/SGSN 1514over the S1 interface is shown below in Table 1.

TABLE 1 IE type and Assigned IE/Group Name Presence Range referenceSemantics description Criticality Criticality Message Type M 9.2.1.1 YESignore eNB WTRU S1AP M 9.2.3.4 YES reject ID NAS-PDU M 9.2.3.5 YESreject TAI M 9.2.3.16 Indicating the Tracking YES reject Area from whichthe WTRU has sent the NAS message. E-UTRAN CGI M 9.2.1.38 Indicating theE-UTRAN YES ignore CGI from which the WTRU has sent the NAS message. RRCEstablishment M 9.2.1.3a YES Ignore cause S-TMSI O 9.2.3.6 YES rejectCSG Id O 9.2.1.62 YES reject GUMMEI O 9.2.3.9 YES reject Cell AccessMode O 9.2.1.74 YES reject GW Transport O Transport Indicating GW YESignore Layer Address Layer Address Transport Layer 9.2.2.1 Address ifthe GW is collocated with eNB Relay Node O 9.2.1.79 Indicating a relaynode YES reject Indicator

A typical response from the CN may be the Initial Context Setup Requestmessage that may be used to inform the eNB 1532 to setup a context for arespective WTRU 102. The message may include an identifier assigned bythe MME 1514 that the eNB 1532 may use when the eNB 1532 desires tocommunicate (e.g., with the MME/SGSN 1514) information that is relatedto a particular WTRU 102. The identifier may be referred to as a MMEWTRU S1AP ID and may be included in the Initial Context Setup Request(ICSR). The ICSR message may be sent by the MME/SGSN 1514 to request thesetup of a WTRU 102 context and may include the contents as shown belowin Table 2 (e.g., including the eNB WTRU S1AP ID that may be provided bythe eNB 1532 in a first message sent towards the MME/SGSN 1514).

TABLE 2 IE type and Semantics Assigned IE/Group Name Presence Rangereference description Criticality Criticality Message Type M 9.2.1.1 YESreject MME WTRU S1AP M 9.2.3.3 YES reject ID eNB WTRU S1AP M 9.2.3.4 YESreject ID WTRU Aggregate M 9.2.1.20 YES reject Maximum Bit Rate E-RAB toBe Setup 1 YES reject List >E-RAB to Be 1 to EACH reject Setup Item IEs<maxnoofE- RABs> >>E-RAB ID M 9.2.1.2 — >>E-RAB Level M 9.2.1.15Includes QoS — QoS Parameters parameters >>Transport M 9.2.2.1 — LayerAddress >>GTP-TEID M 9.2.2.2 — >>NAS-PDU O 9.2.3.5 — >>Correlation ID O9.2.2.80 YES ignore WTRU Security M 9.2.1.40 YES reject CapabilitiesSecurity Key M 9.2.1.41 The KeNB may be YES reject provided after thekey-generation in the MME Trace Activation O 9.2.1.4 YES ignore HandoverO 9.2.1.22 YES ignore Restriction List WTRU Radio O 9.2.1.27 YES ignoreCapability Subscriber O 9.2.1.39 YES ignore Profile ID for RAT/Frequencypriority CS Fallback O 9.2.3.21 YES reject Indicator SRVCC O 9.2.1.58YES ignore Operation Possible CSG O 9.2.1.73 YES ignore MembershipStatus Registered LAI O 9.2.3.1 YES ignore GUMMEI O 9.2.3.9 This IEindicates YES ignore the MME serving the WTRU MME WTRU O 9.2.3.3 This IEindicates YES ignore S1AP ID 2 the MME WTRU S1AP ID assigned by the MME

For a respective WTRU 102, to setup a context at the eNB 1532, the eNB1532 may send the first uplink (UL) NAS message to the CN, which thenmay trigger the context setup request from the CN (e.g., the MME/SGSN1514). An H(e)NB generally refers to a HeNB, HNB, and/or CSG, amongothers. There may not be a context setup request that originates fromthe CN without any trigger, such as receiving an initial NAS messagefrom the eNB.

FIG. 16 is a diagram illustrating a representative Service Requestprocedure 1600, which may lead to the setting up of a context at the eNB1532 for the particular WTRU 102.

Referring to FIG. 16, at 1610, a NAS Service Request message may be sentfrom the WTRU 102 to the eNB 1532. At 1620, a NAS Service Requestmessage may be sent or forwarded from the eNB 1532 to the MME/SGSN 1514.At 1630, the MME/SGSN 1514 may authenticate the WTRU 102 using, forexample, a Home Subscriber Server (HSS) 1602.

At 1640, an S1-AP Initial Context Setup Request message may be sent fromthe MME/SGSN 1514 to the eNB 1532. The Initial Context Setup Requestmessage may include any of following parameters: (1) the E-RAB to besetup (e.g., that may identify the radio bearer to be setup by the eNB)and/or the QoS parameters that may be associated to each bearer; (2) theWTRU Security Capabilities and/or Security Key that may be used by theeNB 1532 to establish a secure communication with the WTRU 102 on theradio interface; and/or (3) other information elements, among others.

At 1650, the eNB 1532 may initiate with the WTRU 102 a Radio BearerEstablishment (RBE). The RBE may include information, such as a bearerreference and QoS parameters. At 1660, uplink data may be provided bythe WTRU 102 to the eNB 1532, SGW 1512 and/or PGW 1604, for example tosynchronize the uplink data between the WTRU 102, the eNB 1532, the SGW1512 and/or the PGW 1604. After the uplink data is received, at 1670, anInitial Context Setup Complete message may be sent by the eNB 1532 tothe MME/SGSN 1514.

At 1675, a Modify Bearer Request message may be sent from the MME/SGSN1514 to the SGW 1512 and, at 1680, the Modify Bearer Request message maybe sent (or forwarded) by the SGW 1512 to the PGW 1604.

In certain representative embodiments, at 1685 a Policy and ChargingEnforcement Function (PCEF) Initiated Internet Protocol ConnectivityAccess Network (IP-CAN) Session Modification message may be sent betweenthe PGW 1604 and the Policy and Charging Rules Function (PCRF) 1606.

At 1690, a Modify Bearer Response may be sent from the PGW 1604 to theSGW 1512 and, at 1695, the Modify Bearer Response message may be sent(or forwarded) by the SGW 1512 to the MME/SGSN 1514.

In certain representative embodiments, RRC integrity protection may beprovided over the radio interface and the eNB 1532 may run the securityprocedure (Security Mode Command) with the WTRU 102 before further RRCsignaling or user data may be exchanged.

In certain representative embodiments, if the data path is via aHNB/HeNB 1522 that is part of the LN 1520, a procedure may be used tosetup the connection between the LGW 1540 and the HNB/HeNB 1522 and/orthe same or a different procedure may be used to setup the connectionbetween the HNB/HeNB 1522 and the SGW 1512. Typically, a context may besetup at the RAN nodes when a specific node forwards an initial NASmessage to the CN.

In certain representative embodiments, for the MRA procedure, a contextmay be setup at the HNB/HeNB 1522 that is not serving the WTRU 102 froma radio perspective (e.g., as an access point). The HNB/HeNB 1522 maynot be the entity that sends the initial NAS message to the CN to setupthe context at the HNB/HeNB 1522. In certain representative embodiments,another cell (e.g., the eNB of another cell) may send the initial NASmessage and may trigger a setup of context in the eNB 1532 and/or at theHNB/HeNB 1522 that may be part of the MRA data path.

The HNB/HeNB 1522 may not be serving the WTRU 102 from a radioperspective and the HNB/HeNB 1522 may be setup to receive and respond tothe Initial Context Setup Request message for a WTRU 102 that is notbeing served by the HNB/HeNB 1522. The HNB/HeNB 1522 may be providedwith an identifier to be used by the MME/SGSN 1514 (e.g., the eNB WTRUS1AP ID). The HNB/HeNB 1522 may use the security parameters and mayinterpret the E-RAB to be setup for a WTRU 102 that is not being servedat the radio level. In the MRA mode, the HNB/HeNB 1522 may not forward(e.g., may not directly forward) the data to the WTRU 102, the HNB/HeNB1522 may send the data to an entity or resource in the CN and anindication (e.g., an MRA indicator) may be used to inform the HNB/HeNB1522 about its MRA procedures/behaviors. The MRA indicator may be usedby the HNB/HeNB 1522 (and/or the LGW 1540) to differentiate the MRAbearers/sessions from other bearers/sessions (e.g., LIPAbearers/sessions, SIPTO bearers/sessions, and/or other bearers/sessions)such that a differentiated treatment such as a differentiated packetforwarding path, and/or a differentiated QoS, among others may berendered.

Typically, the SGW 1512 has (e.g., only has) one active S1 connectionfor the respective WTRU 102. If the MRA data path has to traverse (e.g.,go through) the HNB/HeNB 1522 and the SGW 1512 for downlink traffic, theprocedures or behavior in the SGW 1512 may be changed or modified suchthat more than one S1 connection may be simultaneously active for therespective WTRU 102.

A Local Home Network (LHN) may include multiple HeNBs and/or HNBs 1522and multiple LGWs 1540. During the MRA call establishment, adetermination may occur of which particular HNB/HeNB 1522 and/or LGW1540 may be used as an entry point into the LN being access. The timingduring the MRA session establishment and selection may be established asset forth below.

When the network supports enhanced mobility procedures and when anactive MRA connection exists, the MRA service may be billed differentlyfrom the LIPA service. If a service started as a LIPA service andevolved into an MRA service, the information may be provided to the CNsuch that the service may be charged, accordingly. During CN mobility,the transition from LIPA to MRA or from MRA to LIPA may be detected viatriggers, which may be reported to the CN.

In typical handover (HO) procedures, after the HO is completed, thesource cell may release resources (e.g., all resources) that are beingused for the respective WTRU 102. The resources may include radio and/orS1 resources. In a LIPA to MRA HO, if the source HNB/HeNB 1522 is toremain in the data path for MRA, the current resource release proceduremay not be used as it may clear the resources (e.g., all of theresources) that were established for the LIPA. For the MRA, the HNB/HeNB1522 may forward data to the SGW 1512 such that a procedure may be usedto indicate the MRA to the HNB/HeNB 1522 that is in the data path. Otherprocedures (e.g., with similar methods/behaviors) may be used for theHNB/HeNB and LGW interface. The SGW 1512 may have one or more S1connection for a respective WTRU 102 and the MRA functionality may useenhanced procedures to indicate the WTRU's capabilities to the SGW 1512that more than one S1 connection may be used for the respective WTRU102.

In certain representative embodiments, the MRA data path may be fixed(e.g., always fixed). In certain representative embodiments, the MRAdata path may be dynamic (e.g., changed based on a condition or atriggering event). In certain representative embodiments, the downlinkand uplink paths may follow the same line or paths but may be reversedin direction. In certain representative embodiments, the downlink pathand uplink path may be different.

In certain representative embodiments, MRA procedures may enable idlemode mobility when either a LIPA or an MRA session is active for therespective WTRU 102. For example, such procedures may address problemthat may otherwise arise.

A first problem may include a WTRU 102 that may be in idle mode whileits NAS EPS bearers (e.g., PDN connection and associated bearers) remainactive in the WTRU 102 (and the CN) even if no radio or CN resources arebeing used. For example, an idle mode WTRU 102 with a LIPA PDNconnection may maintain a LIPA PDN connection and associated bearersuntil a condition is met to deactivate the PDN connection and/or theLIPA bearers. As an example, when the MME/SGSN 1514 notices that theWTRU 102 has moved out of the HeNB or HNB (e.g., the coverage area ofthe HeNB or HNB 1522) where the LIPA session was activated, the MME/SGSN1514 may deactivate the associated PDN connection. With the MRAprocedures, the WTRU's mobility in idle mode may not cause the PDNdeactivation, when the CN notices that the WTRU has moved out (e.g.,mobility out) of the LN. If the WTRU 102 is allowed to (and/orconfigured to) have an MRA (e.g., MRA session) when the WTRU 102 movesout of the LN (while in idle or connected mode), the MME/SGSN 1514 maynot deactivate the LIPA PDN connection and may resume the PDN connectionas an MRA session. In certain representative embodiments, the WTRU 102going from (e.g., transitioning from) idle mode to connected mode may doso: to enable signaling (e.g., periodic updates) and/or to establish auser plane. In certain representative embodiments, CN procedures may beimplemented regarding the LIPA PDN connection when the WTRU 102 moveswhile in idle mode and sends a NAS message (e.g., for either signalingor to send user data, among others).

As a second problem, if the WTRU 102 is allowed to have an MRA from itscurrent cell, the WTRU 102 is performing only signaling (e.g., aperiodic Tracking Area Update (TAU)) and does not use the user plane,the MME/SGSN 1514 may or may not take any actions to change the LIPAsession (e.g., an existing LIPA session) to a MRA session.

As a third problem, when the WTRU 102 is not allowed to have MRA, if theWTRU 102 is signaling (e.g., a TAU), the MME/SGSN 1514 may notdeactivate the LIPA PDN connection even if the WTRU 102 cannot have LIPAor MRA from its current location as the WTRU 102 may move back to theHeNB or HNB 1522 (e.g., the coverage area of the HeNB or HNB 1522) wherethe LIPA may be provided.

Although the representative embodiments are discussed usingrepresentative examples, the representative procedures may apply to anyLTE and/or 3G/GERAN system.

MRA Connection Setup: HNB Selection and Setup of Resources

The WTRU 102 may be in a cell where LIPA is not allowed (for example, amacro or HNB cell that is not part of the LN, or in a CSG cell that ispart of the LN but LIPA is not allowed due to subscription). Certainrepresentative embodiments may apply to either the PDN connectionprocedure that can be standalone or part of the Attach procedure.

In certain representative embodiments, the selection of HNB/HeNB 1522for MRA session setup, the procedure used to setup MRA context at aHNB/HeNB 1522, and signaling procedure used to setup resources betweenthe affected nodes e.g., the HNB/HeNB 1522, the LGW 1540, and/or the SGW1512 may be provided.

For example, when the MME/SGSN 1514 receives a PDN Connection requestfor the MRA, the MME/SGSN 1514 may setup a plurality of user planetunnels (e.g., three extra user plane tunnels, for example: (1) betweenthe SGW 1512 and the HNB/HeNB 1522 in the LHN; (2) between the SGW 1512and the LGW 1540; and (3) between the LGW 1540 and the HNB/HeNB 1522 inthe LHN).

In certain representative embodiments, the establishment of S1-U tunnelbetween the HeNB 1522 and the SGW 1512 may be performed by either theHeNB 1522 in the LHN or the SGW 1512. The MME 1514 may send a createsession request (CSR) in a CSR message to the SGW 1512. The CSR messagemay include the address of the HeNB 1522 and/or the address of the LGW1540, which may be used to establish the tunnel between the HeNB 1522and the LGW 1540. The MME 1514 may, via any S1AP message (used for theS1-MME interface), inform the HeNB 1522 that the S1-U tunnel may becreated for a MRA PDN connection so that packets received by the HeNB1522 will be forwarded to the SGW (e.g., and may be achieved by the MME1514 sending an indication to the HeNB 1522 while setting up the S1-Utunnel. The indication may be in the form an IE in a current S1-APmessage (e.g., a Context Setup Request) or a new S1-AP message for MRAenablement). When the HeNB 1522 receives packets from the LGW 1540, theHeNB 1522 may use the indication (or based on this indication that maybe saved in the HeNB as part of the WTRU's context) to send or forwardthe packets towards the SGW 1512. The LGW address that may be sent tothe HeNB 1522 in any S1AP message may serve as an indication to the HeNB1522 that the tunnel is established for a MRA connection even though theWTRU 102 is not being served by the HeNB from a radio perspective.

After the HeNB 1522 receives a request (e.g. in any S1AP message) tocreate a session or connection with the SGW 1512 for the MRAconnection/service, the HeNB 1522 may in addition create the tunnelbetween itself and the LGW 1540. The HeNB 1522 may receive the LGWaddress in the message from the SGW 1512 or the MME 1514. The HeNB 1522may use this address to establish the connection with the LGW 1540. Whenthe LGW 1540 is co-located with the HeNB 1522, the HeNB 1522 may not usethis address, which may be discarded. The HeNB 1522 may send anindication to the LGW 1540 indicating that the tunnel is beingestablished for a MRA PDN connection and may be accomplished either byforwarding the same indication, which the HeNB 1522 receives from theMME 1514 or the SGW 1512, or by sending a new type of indication.

In the case where the HeNB 1522 and the LGW 1540 cannot exchange controlplane messages directly, a user plane tunnel may be established by theSGW 1512 sending a Create Bearer Request (CBR) message to the LGW 1540.The CBR message may include the address of the HeNB 1522 and anindication that the connection is being established for the MRA. The CBRmessage may establish the S5 connection between the LGW 1540 and the SGW1512. Upon reception of the CBR by the LGW 1540 with an indication thatthe connection is for an MRA connection, and/or with a HeNB address, theLGW 1540 may establish a tunnel with the HeNB 1522 (via the interfacethat connects both entities together) and inform the HeNB 1522 that theconnection is an MRA connection. The LGW 1540 may provide the SGWaddress that the LGW 1540 may have received in the CBR message from theSGW 1512.

In certain representative embodiments, the HeNB or HNB 1522 selectionduring MRA session setup may include the following.

(1) The MME/SGSN 1514 may already be configured such that a particularHNB/HeNB 1522 is selected (e.g., always selected) for the MRA. TheHNB/HeNB 1522 selection and configuration at the MME/SGSN 1514 may bebased on operator policies. The MME/SGSN 1514 may have a list of suchHNBs/HeNBs 1522 that it may select in a priority order. For example, ifthe session fails with a selected HNB/HeNB 1522, the MME/SGSN 1514 mayretry with another selection of the HNB/HeNB 1522.

(2) When the MME/SGSN 1514 receives a request to setup an MRAsession/connection, the MME/SGSN 1514 may select a CSG/HNB/HeNB that isallowed to be accessed by the WTRU 102. For example, the MME/SGSN 1514may perform a CSG access check for the respective WTRU 102 as if theWTRU 102 was accessing that cell from the radio perspective. If theaccess check fails, the MME/SGSN 1514 may reject the connection and maysend a reject cause to the WTRU 102 to inform the WTRU 102 about thereason for the rejection. The reject cause may be an existing cause or anew cause (e.g., “cause #25—not allowed on CSG” with a modification suchthat the WTRU 102 knows that this is for a CSG that is not beingaccessed by the WTRU 102 from the radio perspective). The new code maybe defined to indicate that the reason for rejecting an MRA session(e.g., PDN connection) may be due to CSG subscription failure at theselected HNB/HeNB 1522. The MME/SGSN 1514 may include a CSG ID for whichthe access check failed. When the WTRU 102 receives the reject cause,the WTRU 102 may remove the CSG ID from its whitelist (e.g., even thoughthe WTRU 102 did not receive a cause code while in the radio coverage ofthe CSG/HNB/HeNB 1522 for which the access check failed). When the WTRU102 receives the reject cause with the additional indication as to whythe session failed, the WTRU 102 may not initiate a PDN connection forthe same MRA session (e.g., which is identified by a well known APN) fora known or preconfigured time duration, or until the WTRU's CSG lists(e.g., the allowed list and/or the operator list) are modified.

In certain representative embodiments, the MME/SGSN 1514 may not rejectthe connection and may attempt (e.g., try) to select another HNB/HeNB1522 that the WTRU 102 may be a member of. The MME/SGSN 1514 may stillselect a HNB/HeNB 1522 that the WTRU 102 is not a member of, if theresources at the HNB/HeNB 1522 allow (e.g., policies/rules allow) theselection or if the network operator may allow such a selection (e.g.,at the same, higher or different charging rate/fee). The MME/SGSN 1514may prioritize: (1) the selection of the HNB/HeNBs 1522 for which a WTRU102 may be a member; (2) selection of the HNB/HeNBs 1522 that mayoperate in a hybrid mode; and/or (3) the HNB/HeNBs 1522 that are notallowed to be accessed by the WTRU 102 (e.g., if such a selection ispermitted by dynamic or pre-established rules). The prioritizes may bein the order set forth above or in any other order set forth in thepolicies/rules for such prioritization.

In certain representative embodiments, MRA session setup may include thefollowing.

(1) When the MME/SGSN 1514 receives a request to setup an MRA PDNconnection (session), the MME/SGSN 1514 may verify with the HNB/HeNB1522 whether resources allow the setup of such a connection by, forexample, using an explicit message. The message may be sent to theHNB/HeNB 1522 before the setup of the PDN connection. If the message isreceived by the HNB/HeNB 1522, the HNB/HeNB 1522 may respond to indicatewhether resources allow such a connection to take place (e.g., aconnection between the HNB/HeNB 1522 and the LGW 1540). In certainrepresentative embodiments, the MME/SGSN 1514 may continue with theprocessing and setup of the connection. The HNB/HeNB 1522 may rejectsuch a connection, if resources are not available. The HNB/HeNB 1522 maytake into account the WTRU's CSG subscription information to determineor decide on either permitting or rejecting the connection. The MME/SGSN1514 may provide the information in the messages (e.g., all the messagessuch as but not limited to S1AP messages) that are sent to the HNB/HeNB1522 for setting up an MRA connection. A HNB/HeNB 1522 may release theresources for an MRA session, if: (1) the WTRU 102 is not a member ofthe HNB/HeNB 1522, (2) the HNB/HeNB 1522 is experiencing congestion;and/or (3) member WTRUs 102 are accessing the cell.

During the setting of the MRA connection, the HNB/HeNB 1522 may rejectthe request, if resources are not available at the HNB/HeNB 1522 and,for example, the request may be signaled directly to the MME/SGSN 1514using an explicit new or existing message. In certain representativeembodiments, the HNB/HeNB 1522 may signal the rejection and therejection cause to the LGW 1540, which may forward the indication to theMME/SGSN 1514. When the MME/SGSN 1514 receives an indication aboutfailure to setup the MRA session due to rejection at the HNB/HeNB 1522(e.g., for any reason), the MME/SGSN 1514 may select another HNB/HeNB1522, as described above, or the MME/SGSN 1514 may provide the MRAsession using an alternative path for the data (e.g., via the SGW 1512).The MME/SGSN 1514 may select the data path for the MRA based onresources availability or network policies such that in one case thedata path may involve a HNB/HeNB 1522 in the LN 1520, or the data pathmay not involve any HNB/HeNB 1522 in the LN 1520.

It is contemplated to have a procedure in which, for example, theMME/SGSN 1514 may setup a context at the RAN nodes (e.g., the HNB/HeNB1522 or any other RAN node such as an eNB, among other) even if thesenodes may not be serving the WTRU 102 on the radio interface. The CN(e.g., the MME/SGSN 1514) may use a new message or an existing messageon the S1 interface to enable the procedure such that the message mayinclude an indication for the setup of a context that may not be usedfor radio resource provisioning. The new or enhanced existing message(e.g., the Initial Context Setup Request message) may include: (1) anindication to notify the RAN node (e.g., the HNB/HeNB) that theconnection may involve resources on the S1AP interface and otherinterfaces (e.g., the Sxx interface between the HNB 1522 and the LGW1540). For example, the connection type may be defined to indicate “MRAonly” or “CN resources only” and/or “no radio resource”. With theindication, the HNB/HeNB 1522 may setup (e.g., only setup) theappropriate context such that no radio resources are involved and otherradio-related procedures are executed.

An identifier (e.g., “MME WTRU S1AP ID”) may be included by the MME/SGSN1514 and may be unique. The MME/SGSN 1514 may maintain (e.g., keep) amapping between the identifiers used with the HNB/HeNB 1522 and otheridentifiers used with the serving cell with (e.g., under) which the WTRU102 is being served with radio coverage.

An identification of the LGW 1540 to which the HNB/HeNB 1522 may connectmay be included. At least one correlation ID may be provided.

If the MME/SGSN 1514 uses an existing message, the MME/SGSN 1514 maytake the above set forth actions. The MME/SGSN 1514 may not includeparameters (e.g., any parameter) that are used for operation on theradio interface. For example, the MME/SGSN 1514 (or any equivalent CNnode) may not include the security parameters and/or the E-RAB to besetup. The MME/SGSN 1514 may include NAS identifiers that have beenassigned to this WTRU 102 (e.g., S-TMSI, and the like). The HeNB/HNB1522 may store any NAS identifiers that are received from the MME/SGSN1514.

When the HNB/HeNB 1522 receives a new or existing message with anindication to setup resources for an MRA session, the HNB/HeNB 1522 mayrespond to the request to confirm that the procedure is to be or isbeing processed.

In certain representative embodiments, the response may be sent afterthe procedure is executed. The HNB/HeNB 1522 may use a new indication toknow or to determine that the context is for (or relates to) an MRA fora session that does not involve the use of radio resources for therespective WTRU 102. The HNB/HeNB 1522 may allocate an identifier forthis WTRU 102 (e.g., the HNB/HeNB 1522 may allocate and may include anidentifier (e.g., “eNB WTRU S1AP ID”) in the response to the CN). TheHNB/HeNB 1522, responsive to the new message or indicators, may notsetup any radio resource with any of the existing WTRUs 102 and may nottreat the procedure as an erroneous procedure. The eNB 1532 may storeany security parameters that are provided by the CN. In certainrepresentative embodiments, no security procedure may be run with anyWTRU 102. The eNB 1532 may assign a virtual C-RNTI (Cell-Radio NetworkTemporary Identifier) for the WTRU 102 in question so that when the WTRU102 is served by this eNB 1532, the C-RNTI may be directly used toidentify the WTRU 102 at the cell level.

The HNB/HeNB 1522 may use the new or existing indicator (e.g.,correlation ID) with any provided LGW address, for example, to establisha data path with the LGW 1540.

Certain representative embodiments may apply to 3GPP Release 10 (e.g.,the LGW, for example being collocated with the HNB/HeNB 1522) and/or3GPP Release 11 (e.g., the LGW, for example, being standalone)deployment scenarios.

The HeNB 1522 may establish the S1-U connection with the SGW 1512. TheHeNB 1522 may map the S1-U bearer IDs or Tunnel End IDs (TEIDs) to thatwith the LGW 1540 such that any data received from the SGW 1512 on aspecific TEID or bearer may be forwarded to the LGW 1540 if the mappingmatches the TEID (and/or bearer ID) mapped to (e.g., associated withand/or corresponding to) the LGW 1540. Data (e.g., any data) from theLGW 1540 may be verified against the TEID and if it maps to that of theS1-U bearer, the HeNB 1522 may forward the data to the SGW 1512.

The indications, IEs and new messages that are contemplated may be usedto: (1) setup resources (e.g., similar to or equivalent to a E-RAB SETUPREQUEST); (2) modify resources (e.g., similar to or equivalent to aE-RAB Modify Request), and/or (3) release resources (e.g., similar to orequivalent to a E-RAB Release Indication) with no (e.g., orinsignificant or little) involvement of the radio interface. Forexample, to setup more bearers for the MRA, the CN may use a new message(which may be the same or a new message as described above, e.g., withnew connection type) or it may use the E-RAB Setup Request message withthe indications set forth above. The HNB/HeNB 1522 may setup resourcestowards the LGW 1540 and the SGW 1512, as may be the case for theinitial context setup.

It is contemplated that the same or similar procedures may apply to theWTRU 102 Context Modification Request or a new message with theindications as set forth above may be used.

MRA to LIPA Handover and LIPA to MRA Handover

A MRA to LIPA HO procedure may include after the establishment of thepath or connection (e.g., a direct path) with the LGW 1540 (that may beproviding the LIPA session for a respective WTRU 102), the target HeNB1522 indicating to the MME 1514 that a connection has been established.Responsive to the indication, e.g., as a trigger, the MME 1514 mayinform the SGW 1512 that one (e.g., only one) S1-U connection may beactive with the HeNB 1522 and that the session may currently be a LIPAsession. With the indication or similar indications, the SGW 1512 maynot forward any uplink MRA packets to the HeNB 1522, as may be the caseduring an MRA session. The SGW 1512 may release its resources with theprevious cell (source cell where the WTRU 102 was receiving an MRAservice). For example, the MME 1514 may send a modify bearer requestmessage to the SGW 1512 with an indication of modification of thesession to a LIPA session. The SGW 1512, upon receiving the bearerrequest message, may inform the LGW 1540 that the MRA connection (e.g.,session) has been transformed into a LIPA connection (e.g., session).The SGW 1512 may release its resources that were established with thesource cell. The MME 1514 may inform the SGW 1512 that the firstdownlink packet after the WTRU 102 changes to connected mode from idlemode is to be transmitted towards, for example, the target eNB 1532 inthe neighbor cell. For a LIPA session, when the WTRU 102 moves from idlemode to connected mode, the SGW 1512 may forward the first packet to theHeNB 1522 in the LN 1520 and for a MRA session, the first downlinkpacket is to be sent, for example, to the target eNB 1532 (or any otherAP of a neighboring cell) having an appropriate MRA session established.The indication may be included as part of the bearer modificationrequest message sent by the MME 1514 to the SGW 1512. The SGW 1512 mayuse the indication to change the path for the first downlink packettowards the target eNB 1532.

A LIPA to MRA HO procedure may include, during the HO procedure when theLIPA session is continued as a MRA session, the source HeNB 1522, afterhanding the WTRU 102 over to a target cell, may release (e.g., may onlyrelease) the radio resources and may maintain the S1-U connection withthe SGW 1512. The HeNB 1522 may do this either due to an explicitindication that may be received (e.g., from the MME 1514) during the HOor before the HO (e.g., upon the WTRU 102 context setup procedure, theHeNB 1522 may be informed that specific bearers have such a behavior).

In certain representative embodiments, the HeNB 1522 may query the CNbefore the HO to learn about the bearers that have such a treatment. Asone example, the HeNB 1522 may keep (e.g., always keep) the S1-Uresources unless explicitly informed to release the S1-U and/or S1-APconnection (e.g., for the control plane). For example, the HeNB 1522 mayperform the current HO procedure using the existing signaling. The MME1514 may (if the LIPA session is to be continued as the MRA session)send a message to inform the HeNB 1522 to release (e.g., only release)the radio resources and to maintain the S1 connection (e.g., both forthe user plane and the control plane). The signaling may be a newmessage or may be accomplished via a modification of the WTRU ContextRelease or WTRU Context Modification messages. As another example, theHeNB 1522 may maintain (e.g., keep) the S1 connection based on anindication from the target cell that the bearers have been admitted orallowed, and an indication to identify that the bearers are MRA related.The source HeNB 1522 may release radio related resources and/orparameters (e.g., any radio related resources and/or parameters) whenthe source HeNB 1522 knows or determines that the S1 connection is to bemaintained or when the WTRU 102 is handed over to another cell.

The source HeNB 1522 may not release its direct data path connectionthat is established with the LGW 1540. Thus, the source HeNB 1522 maymaintain its direct connection with the LGW 1540. The proceduresdescribed above (e.g., to maintain the S1 connection) may also be usedto maintain the direct connection between the source HeNB 1522 and theLGW 1540. Similarly, the SGW 1512 may not release the S1 interface withthe source HeNB 1522. The SGW 1512 may maintain the connection using anindication that the session is to be continued as a MRA session or theSGW 1512 may maintain (e.g., always maintain) the connection for a LIPAPDN connection (e.g., any LIPA PDN connection) that may be established.

In certain representative embodiments, the SGW 1512 may be informed tomaintain the LIPA PDN connection upon the initial PDN setup procedurewith an indication that such a treatment is used for specific bearers.The MME 1514 may provide such indications to the SGW 1512. In certainrepresentative embodiments, the HeNB 1522 may provide the indication tothe SGW 1512. For example, if the MME 1514 provides such an indicationto the SGW 1512, the MME 1514 may include the indication in a ModifyBearer Request message. The SGW 1512 may use the indication to informthe LGW 1540 about the change of the LIPA session to the MRA session.The LGW 1540 may be informed about the path used for the MRA connection(e.g., the LGW 1540 may be informed to maintain the path via the HeNB1522 or to change the path via the SGW 1512. The MME 1514 and/or SGW1512 may provide this indication to the LGW 1540. The MME 1514 mayinform the SGW 1512 (e.g. in the Modify Bearer Request message) toestablish a tunnel with the cell/eNB 1532 that is now serving the WTRU102 from a radio perspective (i.e. in the cell where the WTRU 102 is toreceive an MRA service).

In any of the representative procedures set forth herein, maintainingthe S1 connection may include reusing the existing S1 connection withthe given TEIDs or re-assigning new TEIDS (e.g., endpoint IDs). Forexample, after a LIPA to MRA HO, the source HeNB 1522 may use theassigned SGW 1512 TEID for the uplink as the TEID used for MRA packetsin the downlink direction. Even though the HeNB 1522 knows or determinesthe TEID for the SGW 1512 in the uplink data path (e.g., for non-MRA),the HeNB 1522 may use this same TEID to send downlink MRA data packets.The SGW 1512 may reuse the HeNB S1-U TEID as the tunnel to send uplinkMRA data.

In certain representative embodiments, the HeNB 1522 and SGW 1512 maykeep or maintain the S1AP (e.g., control plane) connection and mayre-assign the TEID for the user plane. Such a re-assignment may beaccomplished by the MME 1514 that provides the new TEID to the HeNB1522, for example, by including the information in the above set forthmessages to modify the LIPA to MRA context at the source HeNB 1522. TheMME 1514 may request the SGW 1512 to reassign a TEID for the DL MRApacket during the Bearer Context Modification procedure. The request maybe passed to the HNB as set forth herein. The HeNB 1522 may contact theSGW 1512 and/or may reassign (e.g., directly re-assign) a TEID for theuplink MRA packets.

Different MRA Data Paths

The MME 1514 may change the data path at a predetermined time,periodically or at any time based on a triggering event (e.g., based ona particular or pre-established events occurring) such as adetermination of a 3GPP Release 11 deployment, loading of the LN and/orloading of the serving cell, among others. For example, the MME 1514 maychoose to have the MRA data path go (or be established) via a HeNB 1522in a 3GPP Release 10 deployment scenario, while the data path may bechanged to (or be established) directly from the LGW 1540 to the SGW1512 for the downlink (and vice versa for the uplink) when the HeNB 1522are deployed in a 3GPP Release 11 deployment scenario such as when theLGW 1540 may be standalone.

In certain representative embodiments, the MME 1514 may choose to changethe data path to go from (e.g., directly from) the LGW 1540 to the SGW1512 for the downlink (and vice versa for the uplink) if the HeNB 1522does not or may not have resources to provide for the MRA session.

In certain representative embodiments, the MME 1514 may choose or maydetermine to change the data path such that the HeNB 1522 may be in thedata path if resources become available at the HeNB 1522. For example,the determination of the path by the MME 1514 may be based on availableresources.

In certain representative embodiments, the MRA packets may traversethrough or go via the HeNB 1522 for one direction (e.g., either in thedownlink or uplink direction), and the traffic in the other direction(the uplink direction, for example), may not traverse through or go viathe HeNB 1522. The uplink may be a path from the serving cell to the SGW1512, and from the SGW 1512 to the LGW 1540.

In certain representative embodiments, the MRA data path may be directfrom the HeNB 1522 to the serving cell using an X2 connection in an LTEsystem, or using a Iurh connection for a 3G system.

MRA Access Control

In certain representative embodiments, access control may be provided bythe LGW 1540, the MME 1514 and/or by coordination between the two nodes.The HNB/HeNB 1522 (or the eNB) that may provide coverage to the WTRU102, may perform access control for the MRA service, (e.g., in the caseof direct interface mobility with a non-involved core network). Accesscontrol may be provided by the serving cell that may be an HNB/HeNB thatis not part of the LN, or an HNB/HeNB that is part of the LN beingremotely accessed. The access control may also be based on the MRAaccess check result from the WTRU 102.

FIG. 17 is a diagram illustrating representative access controlscenarios. Referring to FIG. 17, access control may be based on theaccess credentials scenarios, for example, in any of the combinationlisted. The access control may be in accordance with or based on theuser CSG subscription right, the LIPA subscription right, the MRAsubscription right, and/or their association to a specific APNconfiguration.

In certain representative embodiments, the access control may be basedon the APN configuration alone. The access control, in addition to or inlieu of the APN configuration, may be based on, for example, attributesspecific to the LHN being remotely accessed or the LGW 1540 beingremotely accessed. Such attribute may be, for example, LHN subscribergroup membership information (member, not a member, and/or LHN ID, amongothers), or LGW subscriber group membership information (member, not amember, and/or LGW ID, among others).

The information used to perform the access control may be stored in theHSS (or HLR) and may be retrieved from the HSS (or HLR) by the MME/SGSN1514 (and/or MSC. among others) at the time of the MRA PDN connectivityestablishment. If another entity is in charge of performing the accesscontrol, the MME/SGSN 1514 may provide the information to the otherentity during the PDN connectivity establishment procedure. For example,the information may be provided to the LGW 1540 by the MME/SGSN 1514 inthe Create Session Request Message. The information may be provided tothe HeNB that is providing coverage to the WTRU 102 or to the HeNB beingremotely accessed in the WTRU Initial Context Setup Request message(and/or by any of the other messages described herein) or in the BearerSetup Request message. The entities performing access control may beconfigured with (e.g., directly with) information on the WTRUs 102 whichmay be allowed access. The information may include the WTRU IMSI and/orMSISDN number.

The access control may be performed at the time of: (1) an MRA PDNconnectivity establishment; (2) bearer establishment; and/or (3) when aLIPA session evolves into an MRA session.

For example, when a WTRU 102 desire to transition from a LIPA session toa MRA session in a CSG cell, if the HeNB 1522 allows access for CSG,LIPA and MRA and the HeNB being remotely accessed also allows access forCSG, LIPA and MRA to the WTRU 102, the WTRU may be allowed to transitionto the MRA session. As a second example, when a WTRU 102 desire totransition from a LIPA session to a MRA session in a CSG cell, if theHeNB 1522 allows access for CSG and LIPA and does not allow access forMRA and the HeNB being remotely accessed also allows access for CSG,LIPA and MRA to the WTRU 102, the WTRU may be allowed to transition tothe MRA session. As a third example, when a WTRU 102 desires totransition from a LIPA session to a MRA session in a CSG cell, if theHeNB being remotely accessed does not allow access for MRA to the WTRU102, the WTRU is unlikely to be allowed to transition to the MRAsession. As a four example, when a WTRU 102 desire to transition from aLIPA session to a MRA session in a CSG cell, if the HeNB 1522 does notallow access for LIPA to the WTRU 102, the WTRU is unlikely to not beallowed to transition to the MRA session. The shaded matrix in FIG. 17illustrates various combinations of access rights for the hosting partyHeNB 1522 and the HeNB that may be remotely accessed (e.g., as apotential serving cell if an MRA session is allowed) and shows certaincombinations that may enable MRA session transitions.

MRA During Idle Mode Mobility and Mobility in CELL_FACH State

FIG. 18 is a diagram illustrating a WTRU 102 moving out (e.g., outsideof the coverage area) of a LN while in idle mode.

Referring to FIG. 18, when the WTRU 102 moves out (e.g., outside of thecoverage area) of the LN in idle mode, the WTRU 102 may have establisheda LIPA PDN connection and may move out of the LN in idle mode to anothercell from which it initiates a NAS procedure. The WTRU 102 may not beallowed to have LIPA from the cell on which it initiates the NASprocedure. This scenario is discussed herein.

In a first representative case, the MRA may be allowed for the WTRU 102,which initiates a NAS procedure with the CN in a cell where LIPA is notallowed. If the network receives a NAS message for signaling, thenetwork (e.g., only the network) may take actions to transform the LIPAPDN connection to an MRA session if no user plane (e.g., even if no userplane) is expected by the WTRU 102. The actions taken by the networkinvolve the same or similar procedures (e.g., actions) as the HO casewhen a LIPA session is resumed as an MRA session.

In a second representative case, the network may not or does not modifythe LIPA PDN connection (and/or the associated bearers) if (e.g., evenif) the MRA is allowed for the WTRU 102. The network may later resumethe LIPA session, as an MRA session, when the WTRU 102 requests userplane resources or initiates a NAS procedure for user plane resources(e.g., via the service request procedure). If the network receives a TAUmessage with the active flag bit set to 1 (which may indicate that userplane resources are requested by the WTRU 102 via the TAU procedure),the network may respond as if the NAS procedure may be a service requestprocedure. The network, even though it has received a TAU message, mayrespond as if a service request procedure is being processed and mayresume the LIPA session, as an MRA session.

In a third representative case, the MRA may be currently allowed for theWTRU 102, which may initiate a NAS procedure with the CN in a cell wherethe LIPA may not be allowed. The following network procedures/actions:may include one or more of:

(1) if the network receives a NAS message for signalling (e.g., onlysignalling), the network may not deactivate the LIPA PDN connection(e.g., regardless of whether the MRA is allowed or not) for therespective WTRU 102. For example, because the WTRU 102 may return to theHNB/HeNB 1522 where the LIPA was activated and resume the LIPA PDNconnection without having to re-establish the PDN connection again;

(2) if the network receives a NAS message for the user plane, thenetwork may deactivate the LIPA PDN connection (e.g., directly) if theMRA is not allowed for the WTRU 102. The same network behaviour iscontemplated (e.g., responsive to a TAU message being received with anactive flag bit set to 1 (which may indicate user plane resources arerequested by the WTRU 102 via the TAU procedure);

(3) the network may start a timer to initiate a guard period duringwhich the WTRU 102 may return to the LN/HeNB where the LIPA is allowed.If the WTRU 102 does not get served by a cell where LIPA is allowedduring the lifetime of the timer, the network may deactivate the LIPAPDN connection when the timer expires. If the WTRU 102 resumes the LIPAservice before the timer expires, the network may stop the timer. Thenetwork may also stop the timer if the WTRU 102 resumes the session asan MRA session from a cell where the MRA is allowed. The WTRU 102 maystart a timer as explained above when the WTRU 102 leaves the cell orlocal network 1520 where a LIPA PDN connection was established. If thetimer expires and the WTRU 102 does not return to the cell or localnetwork 1520 where LIPA session was established, the WTRU 102 may send aNAS message e.g. TAU to the MME 1514. The WTRU 102 may indicate that ithas deactivated the LIPA PDN connection or the bearers that wereassociated with the LIPA PDN connection.

The same or a similar network behavior is contemplated for the case whena WTRU 102 with LIPA session performs cell reselection in CELL_FACHstate (e.g., an RRC connected mode in a 3G system) to a cell where theMRA is allowed. When the CN (e.g., SGSN) notices that the WTRU 102 hasmoved to a new cell, the CN may verify if the MRA is allowed for therespective WTRU 102 (when an LIPA PDN connection has been established).If the MRA is allowed, the network may take the same actions asdescribed for connected mode mobility and session setup to resume theLIPA session, as an MRA session.

MRA Activation During Inter RAT Idle Mode Reselection

In certain representative embodiments, the MRA may be activated when aWTRU 102 reselects from LTE (e.g., with LIPA bearers active) to UTRAN.The MRA may be triggered, for example, by allowing a user request:(1)(i) that the LIPA connection be maintained, and/or (ii) that thecurrent Local Service be maintained; and/or (2) pre-configuring the WTRU102 to request the MRA when reselecting to a new cell. The new cell maybe a UTRAN cell. If the Idle state Signaling Reduction (ISR) is active,and no signaling connection exists, although LIPA bearers may still beactive, the WTRU 102 may request to maintain the service by sending aService Request (or any other NAS message) indicating the MRA. The WTRU102 itself may indicate what bearers are LIPA bearers or the MME 1514may provide the SGSN with the information.

In certain representative embodiments, the MME 1514 may provide the SGSNwith the LIPA (or LIIP) bearer information during a ContextRequest/Response procedure. The information along with, for example,user request and/or MRA subscription pre-configuration, among others,may allow the SGSN to trigger MRA connectivity for LIPA bearers. TheWTRU 102 may provide the LIPA bearer information to the SGSN (e.g.,through an enhanced or new Service Request) indicating which bearers areLIPA bearers. The WTRU 102 may get the information from the MME 1514thorough the PDN Connectivity Type. The WTRU 102 may indicate whether auser desires to tear down, release, or deactivate the LIPA bearers orthe user desires to keep or maintain them as MRA bearers. The WTRU 102may provide the information through the 3G enhanced Service Requestmessages (e.g., for an ISR case) or through a RAU message, if ISR is notactive.

Other Architecture Alternative Solutions for MRA

A representative architecture may be realized which may depending on orbe based on the LGW 1540 deployment architecture: for example, (a) withSxx that may be user plane (e.g., user plane only); (b) with Sxx thatmay be both user plane and control plane; and/or (c) with a StandaloneLGW 1540 on the S1/Iuh path.

In certain representative embodiments, the MRA may also be realized withthe core network being bypassed in the user plane or in both the userplane and the control plane. This may be the case for the scenarioswhere direct interface based procedures are used between the macronetwork and the femto network. An example of the user plane path mayinclude: (1) for UMTS: LGW->HNB->HNB-GW->NB on DL for user plane only orboth user plane and control plane and the reverse path may apply in theuplink direction; (2) for LTE: LGW->HeNB->HeNB-GW->eNB (orLGW->HeNB-eNB) on DL for user plane (e.g., user plane only) or both userplane and control plane and the reverse path may apply in the uplinkdirection.

Another representative architecture may include bypassing the HNB/HeNB1522 and accessing the local home network directly through the LGW 1540(e.g., (1) through CN: LGW->SGW->serving cell->WTRU for DL MRA packets(and the reverse direction for UL packets); and/or (2)LGW->H(e)NB-GW->serving cell->WTRU for DL with the reversed directionfor UL packets) for a direct interface.

It is contemplated that all of the representative architectures may beimplemented with the same or similar procedure as set forth above toenable LIPA to MRA or MRA to LIPA session operations.

FIG. 19 is a flow chart illustrating a representative handover method.

Referring to FIG. 19, in the representative handover method 1900, a WTRU102 may move between, for example, a local network 1320 and anothernetwork 1330 and the WTRU 102 may have established a communicationsession, as a LIPA session, in the local network 1320 via a first AccessPoint (AP) 1322. At block 1910, the first AP 1322 may handover thecommunication session with the WTRU 102 to the second AP 1332 and acommunication path may be established at least between the first AP 1322and the second AP 1332. At block 1920, the first AP 1322 may relaypackets that are associated with the communication session via theestablished communication path towards the second AP 1332.

In certain representative embodiments, the handing over of thecommunication session may include the first AP 1322 maintaining at leastone wireless resource between the first AP 1322 and the WTRU 102 priorto the handover of the communication session and discontinuing the atleast one wireless resource between the first AP 1322 and the WTRU 102after the handover.

In certain representative embodiments, the maintaining of the at leastone wireless resource prior to the handover of the communication sessionmay include maintaining at least one radio bearer between the first AP1322 and the WTRU 102; and the discontinuing of the at least onewireless resource between the first AP 1322 and WTRU 102 may includeterminating the at least one radio bearer between the first AP 1322 andthe WTRU 102.

In certain representative embodiments, the LIPA session between thefirst AP 1322 and the WTRU 102 may be transitioned to a MRA sessionusing the second AP 1332.

In certain representative embodiments, the discontinuing of the wirelessresources between the first AP 1322 and the WTRU 102 may be based oncompletion of the transitioning of the LIPA session to the MRA session.

In certain representative embodiments, the discontinuing of the wirelessresources between the first AP 1322 and the WTRU 102 may occur: (1) atthe same time as the discontinuing of the LIPA session; (2) after thetransitioning to the MRA session based on a trigger condition; or (3) ata predetermined time after the transitioning to the MRA session.

In certain representative embodiments, the communication path betweenthe first AP 1322 and the second AP 1332 may be established by settingthe communication path to traverse at least one gateway 1312 disposedoutside of the local network 1320 and the other network 1330.

In certain representative embodiments, the handing over of thecommunication session may include the first AP 1322 discontinuing atleast one wireless resource between the first AP 1322 and the WTRU 102while maintaining a connection with the at least one gateway 1312disposed outside of the local network 1320 and the other network 1330.

In certain representative embodiments, the first AP 1322 may receive arelay indication indicating whether to relay or whether to stop relayingpackets towards the second AP 1332.

In certain representative embodiments, the first AP 1322 may set acontext for managing the WTRU 102 that is being wirelessly served by thesecond AP 1332 and may prevent any allocation of radio resources withthe WTRU 102 while the context is set.

FIG. 20 is a flow chart illustrating a representative setup method.

Referring to FIG. 20, in the representative setup method 2000 forsetting up a communication path for a MRA session in the local networkor another network, a WTRU 102 may have established a communicationsession, as a LIPA session, in the local network 1520 via a first AccessPoint (AP) 1522. At block 2010, a network entity 1514 outside the localnetwork 1520 may receive a request to setup the MRA session. At block2020, the network entity 1514 may send one or more messages to establisha plurality of tunnels for the MRA session to setup the communicationpath at least between the first AP 1522 and a second AP 1532.

In certain representative embodiments, the sending of the one or moremessages may include sending one or more messages to setup a firsttunnel between a gateway 1512 and the first AP 1522 in the local network1520 and to setup a second tunnel between the gateway 1512 and thesecond AP 1532 in the local network 1520 or the other network 1530.

In certain representative embodiments, the sending of the one or moremessages may include sending information or parameters to the first AP1522 exclusive of information or parameters for operation of the radiointerface.

In certain representative embodiments, the network entity may determinethe second AP 1532 to be used for the MRA session in accordance with oneor more access criteria set forth, for example, in the disclosurerelated to FIG. 17 above.

In certain representative embodiments, the network entity 1514 may sendinformation to a gateway 1512 that is an endpoint of at least one of theplurality of tunnels to inform the gateway 1512 that the first downlinkpacket after a specified WTRU 102 transitions to connected mode fromidle mode is to be sent towards the second AP 1532.

In certain representative embodiments, the established LIPA session maybe continued, as the MRA session by controlling a release of radioresources at the first AP 1522.

In certain representative embodiments, the network entity 1514 maymodify a path used for data exchange (e.g., the communication path) bythe WTRU 102 based on a configuration of a local gateway in the localnetwork 1520.

In certain representative embodiments, the network entity 1514 maymodify the communication path used for the WTRU 102 based on anavailable resource e.g., (at the first AP 1522, at the second AP 1532 orbased on loading criteria, among others).

FIG. 21 is a flow chart illustrating another representative handovermethod.

Referring to FIG. 21, in the representative handover method 2100, theWTRU 102 may move between, for example, a local network 1520 and anothernetwork 1530 and the WTRU 102 may have established a communicationsession, as a LIPA session, in the local network 1520 via a first AP1522. At block 2110, the network entity 1514 may determine whether theother network 1530 is allowed to be accessed by the WTRU 102 inaccordance with one or more criteria. At block 2120, the network entity1514 may control establishment of a communication path at least betweenthe first AP 1522 in the local network 1520 and a second AP 1530 in theother network 1530, responsive to a determined result. The controllingof the establishment may include: (1) initiating a first tunnel having afirst tunnel endpoint of a local gateway 1540 and a second tunnelendpoint of the first AP 1522; (2) initiating a second tunnel having afirst tunnel endpoint of a gateway 1512 and a second tunnel endpoint ofthe first AP 1522; and (3) setting the communication path to traversethe first and second tunnels via the gateway 1512 disposed outside ofthe local network 1520 and the other network 1530.

In certain representative embodiments, the network entity 1514 maymodify a downlink path from the local gateway to the WTRU 102 and anuplink path from the WTRU 102 to the local gateway 1540 such that atleast portions of the downlink and uplink paths are different.

In certain representative embodiments, the data path in the MRA sessionfrom the first AP 1522 to the serving cell 1532 (e.g., the second AP)may use an X2 connection in an LTE system, or may use an Iurh connectionfor a 3G system.

In certain representative embodiments, access control may be performedat a time when the LIPA session transitions into the MRA session.

In certain representative embodiments, a NAS procedure may beimplemented in the other network 1530 while the WTRU 102 is in idlemode.

In certain representative embodiments, each connection in the localnetwork 1520 may be maintained for at least a predetermined period; andthe WTRU 102 may transition back to the LIPA session before thepredetermined period expires.

FIG. 22 is a flow chart illustrating a further representative handovermethod.

Referring to FIG. 22, in the representative handover method 2200, theWTRU 102 may move between, for example, a local network 1520 and anothernetwork 1530 and the WTRU 102 may have established a communicationsession, as a LIPA session, in the local network 1520 via a first AP1522. At block 2210, the second AP 1532 in the other network 1530 mayreceive a request form the WTRU 102 to connect to the other network1530. At block 2220, the LIPA session in the local network 1520 may betransitioned to a MRA session in the other network 1530. For example,the transitioning may include establishing a communication path betweenthe first AP 1522 and the second AP 1532 via a gateway 1512, andinforming the gateway 1512 of the transition to the MRA session.

FIG. 23 is a flow chart illustrating an additional representativehandover method.

Referring to FIG. 23, in the representative handover method 2300, theWTRU 102 may move between, for example, a local network 1520 and anothernetwork 1530 and the WTRU 102 may have established a communicationsession, as a MRA session, in the other network 1530 using theestablished communication path between a first AP 1522 and a second AP1532 wirelessly serving the WTRU 102. At block 2310, the first AP 1522may relay packets that are associated with the communication session viathe established communication path towards the second AP 1532. At block2320, the first AP 1522 may establish at least one radio bearer betweenthe first AP 1522 and the WTRU 102. At block 2330, the first AP 1522 maytransition the MRA session between the second AP 1532 and the WTRU 102in the other network 1530 to a LIPA session in the local network 1520using the established at least one radio bearer between the first AP1522 and the WTRU 102.

In certain representative embodiments, the transitioning of the MRAsession to the LIPA session may include the first AP 1522 terminatingrelaying of packets that are associated with the communication sessionvia the established communication path.

In certain representative embodiments, the terminating of the relayingof the packets occurs: (1) at the same time as the transitioning to theof the MRA session to the LIPA session; (2) after the transitioning tothe MRA session based on a trigger condition; and/or (3) at apredetermined time after the transitioning of the MRA session to theLIPA session.

In certain representative embodiments, the established communicationpath between the first AP 1522 and the second AP 1532 may bediscontinued after establishing of the at least one radio bearer betweenthe first AP 1522 and the WTRU 102.

In certain representative embodiments, the first AP 1522 may receive arelay indication indicating whether to relay or whether to stop relayingpackets towards the second AP 1532.

In certain representative embodiments, the first AP 1522 may update aMRA context for managing the WTRU 102 that is being wirelessly served bythe second AP 1532 to a second context for the first AP 1522 towirelessly serve the WTRU 102.

In certain representative embodiments, data from the WTRU 102 during theLIPA session may be sent towards a destination via a local gateway 1540exclusive of any core network 1512 and 1514.

FIG. 24 is a flow chart illustrating a representative terminationmethod.

Referring to FIG. 24, the representative termination method 2400 mayterminate a communication path for a MRA session in the local network1520 or another network 1530 responsive to a LIPA session beingestablished in the local network 1520 via a first AP 1522. At block2410, a network entity 1514 outside the local network 1520 may receive arequest to setup the LIPA session. At block 2420, the network entity1514 may send one or more messages to discontinue at least a firsttunnel between a gateway 1512 and the first AP 1522 in the local network1520 and a second tunnel between the gateway 1512 and the second AP 1532in the local network 1520 or the other network 1530.

In certain representative embodiments, the sending of the one or moremessages may include sending information or parameters to the first AP1522 including information or parameters for operation of the radiointerface between the first AP 1522 and the WTRU 102.

FIG. 25 is a flow chart illustrating yet another representative handovermethod 2500.

Referring to FIG. 25, in the representative handover method 2500, theWTRU 102 may move between the local network 1520 and another network1530 and the WTRU 102 may have established an MRA session via a first AP1522. At block 2510, a request to connect to the local network may bereceived. At block 2520, the MRA session in the other network 1530 maybe transitioned to a LIPA session. For example, the transitioning mayinclude discontinuing an established communication path between thesecond AP 1532 and a local gateway 1540 and informing the local gateway1540 of the transition to the LIPA session.

In certain representative embodiments, data may be sent from the WTRU102 during the LIPA session towards a destination via the local gateway1540 exclusive of any core network 1512 and 1514.

In certain representative embodiments, the network entity 1514 may senda message to inform a second gateway 1512, disposed between the firstand second APs 1522 and 1532, to not forward uplink packets towards thelocal network 1520.

In certain representative embodiments, the transitioning to the LIPAsession may include continuing the LIPA session, as the MRA session, byestablishing radio resources at the first AP 1522.

In certain representative embodiments, the network entity may include atleast one of: (1) a Mobile Management entity 1514; (2) the local gateway1540 or (3) an AP 1522 that does not directly serve the WTRU 102.

FIG. 26 is a flow chart illustrating a representative selection method2600.

Referring to FIG. 26, in the representative selection method 2600, an AP1522 may be selected to enable MRA for a WTRU 102. At block 2610, anetwork entity (e.g., the MME 1514) via its transmit/receive unit mayreceive a request (e.g., a request, for example, for an MRA session fromthe WTRU 102 or second AP 1532). For example, the request may be whilethe WTRU 102 is in connected mode or after the WTRU 102 transitions fromidle mode back to connected mode. At block 2620, the network entity(e.g., the MME 1514) via its processor may determine the first AP 1522to be used for MRA for the WTRU 102 wirelessly served by the second AP1532. The determination may be based on criteria previously describedherein. At block 2630, the network entity 1514 may send one or moremessages to setup the first AP 1522.

FIG. 27 is a flow chart illustrating a representative setup method 2700.

Referring to FIG. 27, in the representative setup method 2700, a MRAsession for a WTRU 102 may be setup via first and second APs 1522 and1532. At block 2710, a gateway (e.g., the SGW 1512) via itstransmit/receive unit may receive a setup message (e.g., to setup aplurality of tunnels with the first AP 1522 and the second AP 1532) Atblock 2720, the gateway (e.g., the SGW 1512) via its processor may setupa first tunnel between the gateway 1512 and the first AP 1522 and asecond tunnel between the gateway 1512 and the second AP 1532.

FIG. 28 is a flow chart illustrating a representative setup method 2800.

Referring to FIG. 28, in the representative setup method 2800, a MRAsession for a WTRU 102 may be setup via an AP 1522. At block 2810, theAP 1522 (e.g., an HeNB or eNB) via its transmit/receive unit may receivea setup message (e.g., indicating a context associated with the WTRU 102that is not being served wirelessly by the AP 1522) For example, theWTRU 102 may be served by AP 1532 which has a different context whichmay include radio resources for the WTRU 102. As another example, the AP1522 may have resource (e.g., for relaying communication towards theWTRU 102 but may not have radio resources used to directly communicatewith the WTRU 102). All resources (radio and/or non-radio resources) maybe set via the context. At block 2820, the AP 1522 may setup via itsprocessor the received context.

FIG. 29 is a flow chart illustrating a representative method 2900.

Referring to FIG. 29, in the representative method 2900, a LIPA sessionfor a WTRU 102 that is moving out of a local network 1520 in idle modemay be managed. At block 2910, a network entity (e.g., the MME 1514) mayreceive via its transmit/receive unit a first message (e.g., a NASmessage associated with the WTRU 102, for example, a tracking areaupdate message or another message as disclosed herein). At block 2920,the network entity 1514 via its processor may determine whether or notto maintain the LIPA session based on the received first message, as adetermined result. For example, the determination of whether to maintainthe LIPA session may be based on the type of message (e.g., the type ofNAS message, whether the message identifies a request, the timing of themessage and/or other criteria as set forth above). At block 2930, thenetwork entity via its transmit/receive unit may send a second messageto maintain or to terminate the LIPA session in accordance with thedetermined result. For example, the LIPA session may be terminated,terminated after a predetermined time if the WTRU 102 does not return tothe local network 1520 or maintained until terminated by an independenttermination triggering event. The LIPA session may be maintained whilethe WTRU 102 is wirelessly served by an AP 1532 outside the localnetwork 1520.

Throughout the disclosure, one of skill understands that certainrepresentative embodiments may be used in the alternative or incombination with other representative embodiments.

Although features and elements are described above in particularcombinations, one of ordinary skill in the art will appreciate that eachfeature or element can be used alone or in any combination with theother features and elements. In addition, the methods described hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer readable medium for execution by a computeror processor. Examples of non-transitory computer-readable storage mediainclude, but are not limited to, a read only memory (ROM), random accessmemory (RAM), a register, cache memory, semiconductor memory devices,magnetic media such as internal hard disks and removable disks,magneto-optical media, and optical media such as CD-ROM disks, anddigital versatile disks (DVDs). A processor in association with softwaremay be used to implement a radio frequency transceiver for use in aWTRU, WTRU 102, terminal, base station, RNC, or any host computer.

Moreover, in the embodiments described above, processing platforms,computing systems, controllers, and other devices containing processorsare noted. These devices may contain at least one Central ProcessingUnit (“CPU”) and memory. In accordance with the practices of personsskilled in the art of computer programming, reference to acts andsymbolic representations of operations or instructions may be performedby the various CPUs and memories. Such acts and operations orinstructions may be referred to as being “executed,” “computer executed”or “CPU executed.”

One of ordinary skill in the art will appreciate that the acts andsymbolically represented operations or instructions include themanipulation of electrical signals by the CPU. An electrical systemrepresents data bits that can cause a resulting transformation orreduction of the electrical signals and the maintenance of data bits atmemory locations in a memory system to thereby reconfigure or otherwisealter the CPU's operation, as well as other processing of signals. Thememory locations where data bits are maintained are physical locationsthat have particular electrical, magnetic, optical, or organicproperties corresponding to or representative of the data bits.

The data bits may also be maintained on a computer readable mediumincluding magnetic disks, optical disks, and any other volatile (e.g.,Random Access Memory (“RAM”)) or non-volatile (“e.g., Read-Only Memory(“ROM”)) mass storage system readable by the CPU. The computer readablemedium may include cooperating or interconnected computer readablemedium, which exist exclusively on the processing system or aredistributed among multiple interconnected processing systems that may belocal or remote to the processing system. It is understood that therepresentative embodiments are not limited to the above-mentionedmemories and that other platforms and memories may support the describedmethods.

No element, act, or instruction used in the description of the presentapplication should be construed as critical or essential to theinvention unless explicitly described as such. Also, as used herein, thearticle “a” is intended to include one or more items. Where only oneitem is intended, the term “one” or similar language is used. Further,the terms “any of” followed by a listing of a plurality of items and/ora plurality of categories of items, as used herein, are intended toinclude “any of,” “any combination of,” “any multiple of,” and/or “anycombination of multiples of” the items and/or the categories of items,individually or in conjunction with other items and/or other categoriesof items. Further, as used herein, the term “set” is intended to includeany number of items, including zero. Further, as used herein, the term“number” is intended to include any number, including zero.

Moreover, the claims should not be read as limited to the describedorder or elements unless stated to that effect. In addition, use of theterm “means” in any claim is intended to invoke 35 U.S.C. §112, ¶6, andany claim without the word “means” is not so intended.

Suitable processors include, by way of example, a general purposeprocessor, a special purpose processor, a conventional processor, adigital signal processor (DSP), a plurality of microprocessors, one ormore microprocessors in association with a DSP core, a controller, amicrocontroller, Application Specific Integrated Circuits (ASICs),Application Specific Standard Products (ASSPs); Field Programmable GateArrays (FPGAs) circuits, any other type of integrated circuit (IC),and/or a state machine.

A processor in association with software may be used to implement aradio frequency transceiver for use in a wireless transmit receive unit(WTRU), user equipment (UE), terminal, base station, Mobility ManagementEntity (MME) or Evolved Packet Core (EPC), or any host computer. TheWTRU may be used m conjunction with modules, implemented in hardwareand/or software including a Software Defined Radio (SDR), and othercomponents such as a camera, a video camera module, a videophone, aspeakerphone, a vibration device, a speaker, a microphone, a televisiontransceiver, a hands free headset, a keyboard, a Bluetooth® module, afrequency modulated (FM) radio unit, a Near Field Communication (NFC)Module, a liquid crystal display (LCD) display unit, an organiclight-emitting diode (OLED) display unit, a digital music player, amedia player, a video game player module, an Internet browser, and/orany Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

Although the invention has been described in terms of communicationsystems, it is contemplated that the systems may be implemented insoftware on microprocessors/general purpose computers (not shown). Incertain embodiments, one or more of the functions of the variouscomponents may be implemented in software that controls ageneral-purpose computer.

In addition, although the invention is illustrated and described hereinwith reference to specific embodiments, the invention is not intended tobe limited to the details shown. Rather, various modifications may bemade in the details within the scope and range of equivalents of theclaims and without departing from the invention.

Representative Embodiments

In at least one embodiment, a method for handover of a WirelessTransmitter/Receiver Unit (WTRU) moving between a local network andanother network or first and second Access Points (APs) in the localnetwork is disclosed, and the WTRU may have established a communicationsession, as a Local IP access (LIPA) session, in the local network viathe first AP. The method may comprise handing over, by the first AP tothe second AP, the communication session with the WTRU, a communicationpath being established at least between the first AP and the second AP;and relaying, by the first AP, packets that are associated with thecommunication session via the established communication path towards thesecond AP.

In at least one embodiment, the handing over of the communicationsession may include maintaining, by the first AP, at least one wirelessresource between the first AP and the WTRU prior to the handover of thecommunication session; and discontinuing, by the first AP, the at leastone wireless resource between the first AP and the WTRU.

In at least one embodiment, the maintaining of the at least one wirelessresource prior to the handover of the communication session may includemaintaining at least one radio bearer between the first AP and the WTRU;and the discontinuing of the at least one wireless resource between thefirst AP and WTRU may include: maintaining, by the first AP, establishedresources with one or more gateways associated with the WTRU anddeactivating the at least one wireless resource that were being used forthe WTRU.

In at least one embodiment, the method may further comprisetransitioning the LIPA session between the first AP and the WTRU to amanaged remote access (MRA) session using the second AP.

In at least one embodiment, the discontinuing of the wireless resourcesbetween the first AP and the WTRU may be based on completion of thetransitioning of the LIPA session to the MRA session.

In at least one embodiment, the discontinuing of the wireless resourcesbetween the first AP and the WTRU may occur: (1) at the same time as thediscontinuing of the LIPA session; (2) after the transitioning to theMRA session based on a trigger condition; or (3) at a predetermined timeafter the transitioning to the MRA session.

In at least one embodiment, the method may further comprise establishingthe communication path between the first AP and the second AP by settingthe communication path to traverse at least one gateway disposed outsideof the local network and the other network.

In at least one embodiment, the handing over of the communicationsession may include discontinuing, by the first AP, at least onewireless resource between the first AP and the WTRU while maintaining aconnection with the at least one gateway disposed outside of the localnetwork and the other network.

In at least one embodiment, the method may further comprise receiving,by the first AP, a relay indication indicating whether to relay orwhether to stop relaying packets towards the second AP.

In at least one embodiment, the method may further comprise: setting, atthe first AP, a context for managing the WTRU that is being wirelesslyserved by the second AP; and preventing, by the first AP, any allocationof radio resources with the WTRU while the context is set.

In at least one embodiment, a method for setting up a communication pathfor a Managed Remote Access (MRA) session in the local network oranother network responsive to a Local IP access (LIPA) session havingbeen established in the local network via a first Access Point (AP) isdisclosed. The method may comprise: receiving, by a network entityoutside the local network, a request to setup the MRA session; andsending, by the network entity, one or more messages to establish aplurality of tunnels for the MRA session to setup the communication pathat least between the first AP and a second AP.

In at least one embodiment, the sending of the one or more messages mayinclude sending one or more messages to setup a first tunnel between agateway and the first AP in the local network and to setup a secondtunnel between the gateway and the second AP in the local network or theother network.

In at least one embodiment, the sending of the one or more messages mayinclude sending information or parameters to the first AP exclusive ofinformation or parameters for operation of the radio interface.

In at least one embodiment, the method may further comprise determining,by the network entity, the second AP to be used for the MRA session inaccordance with one or more access criteria.

In at least one embodiment, the method may further comprise continuingthe established LIPA session, as the MRA session by controlling arelease of radio resources at the first AP.

In at least one embodiment, the method may further comprise modifying,by a network entity, a path used for data exchange by a WirelessTransmitter/Receiver Unit (WTRU) based on a configuration of a localgateway in the local network.

In at least one embodiment, the method may further comprise modifying,by the network entity, a communication path used for a WirelessTransmitter/Receiver Unit (WTRU) based on an available resource at thefirst AP.

In at least one embodiment, a method for handover of a WirelessTransmitter/Receiver Unit (WTRU) moving between another network isdisclosed. The WTRU may have established a communication session, as aLocal IP access (LIPA) session, in the local network via a first AccessPoint (AP). The method may comprise: determining, by a network entity,whether the other network is allowed to be accessed by the WTRU inaccordance with one or more criteria; and; controlling establishment ofa communication path at least between the first AP in the local networkand a second AP in the other network, responsive to a determined resultby: initiating a first tunnel having a first tunnel endpoint of a localgateway and a second tunnel endpoint of the first AP; initiating asecond tunnel having a first tunnel endpoint of a second gateway and asecond tunnel endpoint of the first AP; and setting the communicationpath to traverse the first and second tunnels via the second gatewaydisposed outside of the local network and the other network.

In at least one embodiment, the method may further comprise modifying adownlink path from the local gateway to a Wireless Transmitter/ReceiverUnit (WTRU) and an uplink path from the WTRU to the local gateway,wherein at least a portion of the downlink and uplink paths aredifferent.

In at least one embodiment, the method may further comprise establishingthe data path in the MRA session from the first AP to the serving cellusing an X2 connection in an LTE system, or using Iurh connection for a3G system.

In at least one embodiment, the method may further comprise performingaccess control at a time when the LIPA session transitions into the MRAsession.

In at least one embodiment, the method may further comprise implementinga NAS procedure in the other network while the WTRU is in idle mode.

In at least one embodiment, the method may further comprise maintainingeach connection in the local network for at least a predeterminedperiod; and transitioning back to the LIPA session before thepredetermined period expires.

In at least one embodiment, a method for handover of a WirelessTransmitter/Receiver Unit (WTRU) moving between a local network andanother network is disclosed. The WTRU may have established a Local IPaccess (LIPA) session in the local network via a first Access Point(AP). The method may comprise: receiving, by a second AP in the othernetwork, a request to connect to the other network; and transitioningthe LIPA session in the local network to a Managed Remote Access (MRA)session in the other network by: establishing a communication pathbetween the first AP and the second AP via a gateway, and informing thegateway of the transition to the MRA session.

In at least one embodiment, a method for handover of a WirelessTransmitter/Receiver Unit (WTRU) moving between a local network andanother network is disclosed. The WTRU may have established acommunication session, as a Managed Remote access (MRA) session, in theother network using an established communication path between a first APand a second AP wirelessly serving the WTRU. The method may comprise:relaying, by the first AP, packets that are associated with thecommunication session via the established communication path towards thesecond AP; establishing at least one radio bearer between the first APand the WTRU; and transitioning the MRA session between the second APand the WTRU in the other network to a Local IP access (LIPA) session inthe local network using the established at least one radio bearerbetween the first AP and the WTRU.

In at least one embodiment, the transitioning of the MRA session to theLIPA session may include terminating, by the first AP, the relaying ofpackets that are associated with the communication session via theestablished communication path.

In at least one embodiment, the terminating of the relaying of thepackets may occur: (1) at the same time as the transitioning to the ofthe MRA session to the LIPA session; (2) after the transitioning to theMRA session based on a trigger condition; or (3) at a predetermined timeafter the transitioning of the MRA session to the LIPA session.

In at least one embodiment, the method may further comprisediscontinuing the established communication path between the first APand the second AP after the establishing of the at least one radiobearer between the first AP and the WTRU.

In at least one embodiment, the method may further comprise receiving,by the first AP, a relay indication indicating whether to relay orwhether to stop relaying packets towards the second AP.

In at least one embodiment, the method may further comprise updating, atthe first AP, a MRA context for managing the WTRU that is beingwirelessly served by the second AP to a second context for the first APto wirelessly serve the WTRU.

In at least one embodiment, the method may further comprise sending datafrom the WTRU during the LIPA session towards a destination via a localgateway exclusive of any core network.

In at least one embodiment, a method, a method for terminating acommunication path for a Managed Remote Access (MRA) session in thelocal network or another network responsive to a Local IP access (LIPA)session being established in the local network via a first Access Point(AP) is disclosed. The method may comprise: receiving, by a networkentity outside the local network, a request to setup the LIPA session;and sending, by the network entity, one or more messages to discontinueat least a first tunnel between a gateway and the first AP in the localnetwork and a second tunnel between the gateway and the second AP in thelocal network or the other network.

In at least one embodiment, the sending of the one or more messages mayinclude sending information or parameters to the first AP includinginformation or parameters for operation of the radio interface betweenthe first AP and a Wireless Transmitter/Receiver Unit (WTRU).

In at least one embodiment, a method for handover of a WirelessTransmitter/Receiver Unit (WTRU) moving between a local network andanother network is disclosed. The WTRU may have established ManagedRemote Access (MRA) session via a first Access Point (AP). The methodmay comprise: receiving a request to connect to the local network; andtransitioning the MRA session in the other network to a Local IP Access(LIPA) session by discontinuing an established communication pathbetween the second AP and a local gateway, and informing the localgateway of the transition to the LIPA session.

In at least one embodiment, the method may further comprise sending datafrom the WTRU during the LIPA session towards a destination via thelocal gateway exclusive of any core network.

In at least one embodiment, the method may further comprise sending, bya network entity, a message to inform a second gateway, disposed betweenthe first and second APs, to not forward uplink packets towards thelocal network

In at least one embodiment, the transitioning to the LIPA session mayinclude continuing the MRA session, as the LIPA session, by establishingradio resources at the first AP.

In at least one embodiment, the network entity may include at least oneof: (1) a Mobile Management Entity; (2) the local gateway or (3) an APthat does not directly serve the WTRU.

In at least one embodiment, an access point (AP) for handover of aWireless Transmitter/Receiver Unit (WTRU) moving between a local networkand another network is disclosed. The WTRU may have established acommunication session, as a Local IP access (LIPA) session, in the localnetwork via the AP wirelessly serving the WTRU. The AP may comprise: asend/receive unit configured to relay packets towards a second AP thatare associated with the communication session via a communication pathestablished at least between the first AP and the second AP; and acontroller configured to hand over to the second AP, the communicationsession with the WTRU.

In at least one embodiment, the controller may be configured to:maintain at least one wireless resource between the AP and the WTRUprior to handover of the communication session; and discontinue the atleast one wireless resource between the AP and the WTRU.

In at least one embodiment, the controller may be configured to:maintain at least one radio bearer between the AP and the WTRU prior tohandover; and terminate the at least one radio bearer between the firstAP and the WTRU after the handover.

In at least one embodiment, the controller may be configured todiscontinue the wireless resources between the AP and the WTRU based oncompletion of the handover.

In at least one embodiment, the controller may be configured todiscontinue the wireless resources between the AP and the WTRU: (1) atthe same time as a discontinuation of the LIPA session; (2) after atransition to the MRA session based on a trigger condition; or (3) at apredetermined time after the transition to the MRA session.

In at least one embodiment, the controller may be configured todiscontinue at least one wireless resource between the first AP and theWTRU while maintaining a connection with at least one gateway disposedoutside of the local network.

In at least one embodiment, the send/receive unit may be configured toreceive a relay indication indicating whether to relay or whether tostop relaying packets towards the second AP; and the controller may beconfigured to control relaying of packets based on the received relayindication.

In at least one embodiment, the send/receive unit may be configured toreceive a MRA context for managing the WTRU that is being wirelesslyserved by the second AP; and the controller may be configured to preventany allocation of radio resources with the WTRU in accordance with thereceived MRA context.

In at least one embodiment, a network entity (NE) may be configured tosetup a communication path for a Managed Remote Access (MRA) session inthe local network or another network responsive to a Local IP access(LIPA) session having been established in the local network via a firstAccess Point (AP). The NE may comprise: a send/receive unit configuredto receive a request to setup the MRA session; and a processorconfigured to determine endpoints of tunnels for the MRA session to sendone or more messages in accordance with one or more access criteria,wherein the send/receive unit may be configured to send the one or moremessages to establish the tunnels for the MRA session to setup thecommunication path at least between the first AP and a second AP.

In at least one embodiment, the send/receive unit may be configured tosend information to a gateway which is an endpoint of at least one ofthe plurality of tunnels to inform the gateway that the first downlinkpacket after a specified WTRU transitions to connected mode from idlemode is to be sent towards the second AP.

In at least one embodiment, the NE may be configured to continue theestablished LIPA session, as the MRA session by controlling a release ofradio resources at the first AP.

In at least one embodiment, the NE may be configured to modify a pathused for data exchange by a Wireless Transmitter/Receiver Unit (WTRU)based on a configuration of a local gateway in the local network.

In at least one embodiment, the NE may be configured to modify acommunication path used for a Wireless Transmitter/Receiver Unit (WTRU)based on an available resource at the first AP.

In at least one embodiment, a network entity (NE) may be configured tocontrol handover of a Wireless Transmitter/Receiver Unit (WTRU) movingbetween another network. The WTRU may have established a communicationsession, as a Local IP access (LIPA) session, in the local network via afirst Access Point (AP) wirelessly serving the WTRU. The NE maycomprise: a controller configured to determine whether the other networkis allowed to be accessed by the WTRU in accordance with one or morecriteria and control establishment of a communication path at leastbetween the first AP in the local network and a second AP in the othernetwork, responsive to a determined result such that a first tunnel isinitiated having a first tunnel endpoint of a local gateway and a secondtunnel endpoint of the first AP and a second tunnel is initiated havinga first tunnel endpoint of a serving gateway and a second tunnelendpoint of the first AP, wherein the controller is further configuredto set the communication path to traverse the first and second tunnelsvia the at least one gateway.

In at least one embodiment, an access point (AP) may be configured tohandover a Wireless Transmitter/Receiver Unit (WTRU) moving between alocal network and another network. The WTRU may have established a LocalIP access (LIPA) session in the local network via a first Access Point(AP) wirelessly serving the WTRU. The AP may comprise: a send/receiveunit configured to receive a request to connect to the other network;and a controller configured to transition the LIPA session in the localnetwork to a Managed Remote Access (MRA) session in the other network byestablishing a communication path between the first AP and the second APvia a gateway, and informing the gateway of the transition to the MRAsession.

In at least one embodiment, an access point (AP) may be configured tohandover a Wireless Transmitter/Receiver Unit (WTRU) moving between alocal network and another network. The WTRU may have established acommunication session, as a Managed Remote access (MRA) session, in theother network using an established communication path between a first APand a second AP wirelessly serving the WTRU. The AP may comprise: asend/receive unit configured to relay packets that are associated withthe communication session via the established communication path towardsthe second AP; and a controller configured to establish at least oneradio bearer between the AP and the WTRU; and transition the MRA sessionbetween the second AP and the WTRU in the other network to a Local IPaccess (LIPA) session in the local network using the established atleast one radio bearer between the AP and the WTRU.

In at least one embodiment, the controller may be configured toterminate relaying of packets that are associated with the communicationsession via the established communication path.

In at least one embodiment, the controller may be configured toterminate the relaying of the packets: (1) at the same time as thetransition of the MRA session to the LIPA session; (2) after thetransition to the MRA session based on a trigger condition; or (3) at apredetermined time after the transitioning of the MRA session to theLIPA session.

In at least one embodiment, the controller may be configured todiscontinue the established communication path between the first AP andthe second AP after the establishment of the at least one radio bearerbetween the first AP and the WTRU.

In at least one embodiment, the send/receive unit may be configured toreceive a relay indication indicating whether to relay or whether tostop relaying packets towards the second AP.

In at least one embodiment, the controller may be configured o update aMRA context for managing the WTRU that is being wirelessly served by thesecond AP to a second context for the AP to wirelessly serve the WTRU.

In at least one embodiment, the send/receive unit may be configured tosend data from the WTRU during the LIPA session towards a destinationvia the local gateway exclusive of any core network.

In at least one embodiment, a network entity (NE) may be configured toterminate a communication path for a Managed Remote Access (MRA) sessionin the local network or another network responsive to a Local IP access(LIPA) session being established in the local network via a first AccessPoint (AP). The NE may comprise: a send/receive unit configured toreceive a request to setup the LIPA session; and send one or moremessages to discontinue at least a first tunnel between a gateway andthe first AP in the local network and a second tunnel between thegateway and the second AP in the local network or the other network.

In at least one embodiment, the send/receive unit may be configured tosend information or parameters to the first AP including information orparameters for operation of the radio interface between the first AP anda Wireless Transmitter/Receiver Unit (WTRU).

In at least one embodiment, the NE may include at least one of: (1) aMobile Management entity; (2) a local gateway or (3) an AP, which doesnot directly serve the WTRU.

In at least one embodiment, an access point (AP) for controllinghandover of a Wireless Transmitter/Receiver Unit (WTRU) moving between alocal network and another network is disclosed. The WTRU may haveestablished a Managed Remote Access (MRA) session via the AP and asecond AP wirelessly serving the WTRU. The AP may comprise asend/receive unit configured to receive a request to connect to thelocal network; and a controller configured to control transition of theMRA session to a LIPA session in the local network by managing adiscontinuation of a path between the first AP in the local network andthe second AP in the other network and controlling sending ofinformation to a local gateway to transition to the LIPA session suchthat packets associated the MRA session are not sent toward theestablished path between the first AP and the second AP.

In at least one embodiment, a method for setting up a communication pathfor a Managed Remote Access (MRA) session in the local network oranother network via a first Access Point (AP) is disclosed. The methodmay comprise: receiving, by a network entity outside the local network,a request to setup the MRA session; and sending, by the network entity,one or more messages to establish a plurality of tunnels for the MRAsession to setup the communication path at least between the first APand a second AP.

In at least one embodiment, a method for terminating a communicationpath for a Managed Remote Access (MRA) session in the local network oranothernetwork via a first Access Point (AP) is disclosed. The methodmay comprise: receiving, by a network entity outside the local network,a request; and sending, by the network entity, one or more messages todiscontinue at least a first tunnel between a gateway and the first APin the local network and a second tunnel between the gateway and asecond AP in the local network or the other network.

In at least one embodiment, a network entity (NE) is configured to setupa communication path for a Managed Remote Access (MRA) session in thelocal network or another network via a first Access Point (AP). The NEmay comprise: a send/receive unit configured to receive a request tosetup the MRA session; and a processor configured to determine endpointsof tunnels for the MRA session to send one or more messages inaccordance with one or more access criteria, wherein the send/receiveunit is configured to send the one or more messages to establish thetunnels for the MRA session to setup the communication path at leastbetween the first AP and a second AP.

In at least one embodiment, a network entity (NE) is configured toterminate a communication path for a Managed Remote Access (MRA) sessionin the local network or another network via a first Access Point (AP).The NE may comprise: a send/receive unit configured to receive a requestand send one or more messages to discontinue at least a first tunnelbetween a gateway and the first AP in the local network and a secondtunnel between the gateway and the second AP in the local network or theother network.

In at least one embodiment, a method for selection of an Access Point(AP) for Managed Remote Access (MRA) of a Wireless Transmit/Receive Unit(WTRU) is disclosed. The method may comprise: receiving, by a networkentity, a request; determining, by the network entity, a first AP to beused for MRA for the WTRU wirelessly served by a second AP; and sending,by the network entity, one or more messages to setup the first AP.

In at least one embodiment, a method for setup of Managed Remote Access(MRA) for a Wireless Transmit/Receive Unit (WTRU) via first and secondAccess Points (APs) is disclosed. The method may comprise: receiving, bya gateway, a setup message; and setting up, by the gateway, a firsttunnel between the gateway and the first AP and a second tunnel betweenthe gateway and the second AP.

In at least one embodiment, a network entity (NE) is configured toselect an Access Point (AP) for Managed Remote Access (MRA) of aWireless Transmit/Receive Unit (WTRU). The NE may comprise: atransmit/receive unit configured to receive a request; and a processorconfigured to determine a first AP to be used for MRA for the WTRUwirelessly served by a second AP, wherein the transmit/receive unit isconfigured to send one or more messages to setup the first AP.

In at least one embodiment, a gateway is configured to setup a ManagedRemote Access (MRA) of a Wireless Transmit/Receive Unit (WTRU) via firstand second Access Points (APs). The gateway may comprise: atransmit/receive unit configured to receive a setup message; and aprocessor configured to setup a first tunnel between the gateway and thefirst AP and a second tunnel between the gateway and the second AP.

In at least one embodiment, a method for setup of Managed Remote Access(MRA) for a Wireless Transmit/Receive Unit (WTRU) via an Access Point(AP) is disclosed. The method may comprise: receiving, by the AP, asetup message indicating a context for the WTRU that is not being servedwirelessly by the AP; and setting up, by the AP, the received context.

In at least one embodiment, an Access Point (AP) is configured to setupa Managed Remote Access (MRA) for a Wireless Transmit/Receive Unit(WTRU). The AP may comprise: a transmit/receive unit configured toreceive a setup message indicating a context for the WTRU that is notbeing served wirelessly by the AP; and a processor configured to setupthe received context.

In at least one embodiment, a method for managing a Local IP Access(LIPA) session for a Wireless Transmit/Receive Unit (WTRU) moving out ofa local network in idle mode is disclosed. The method may comprise:receiving, by a network entity, a first message; determining, by thenetwork entity, whether or not to maintain the LIPA session based on thereceived first message, as a determined result; and sending, by thenetwork entity, a second message to maintain or to terminate the LIPAsession in accordance with the determined result.

In at least one embodiment, a network entity is configured to manage aLocal IP Access (LIPA) session for a Wireless Transmit/Receive Unit(WTRU) moving out of a local network in idle mode. The NE may comprise:a transmit/receive unit configured to receive a first message; and aprocessor configured to determine whether or not to maintain the LIPAsession based on the received first message, as a determined result,wherein the transmit/receive unit is configured to send a second messageto maintain or to terminate the LIPA session in accordance with thedetermined result.

1-12. (canceled)
 13. A method for managing a session implemented by anAccess Point for serving a Wireless Transmitter/Receiver Unit (WTRU)moving between first and second Radio Access Technologies (RATs), themethod comprising: receiving, by the Access Point from a network entity,context information; and on condition that the WTRU has a session routedover the first RAT and the WTRU becomes idle: (1) maintaining, by the APin accordance with the received context information, a control planeconnection for the session associated with the WTRU, and (2) suspendingthe user plane connection for the session associated with the WTRU priorto expiry of a timer.
 14. The method of claim 1, further comprisingreleasing the user plane connection for the session after expiry of thetimer.
 15. The method of claim 13, wherein the maintaining of thecontrol plane connection for the session associated with the WTRUincludes maintaining, by the AP, the control plane session associatedwith the WTRU prior to and after the suspension of the user planeconnection.
 16. The method of claim 13, further comprising: handingover, by the AP, as a first AP, to a second AP, the user planeconnection for the session associated with the WTRU, a communicationpath being established at least between the first AP and the second AP;and relaying, by the first AP, data packets that are associated with thesession via the established communication path towards the second AP.17. The method of claim 16, further comprising: maintaining, by thefirst AP, at least one wireless resource between the first AP and theWTRU prior to the handover of the communication session; anddiscontinuing, by the first AP, the at least one wireless resourcebetween the first AP and the WTRU.
 18. A method implemented by a NetworkEntity (NE) for serving a Wireless Transmitter/Receiver Unit (WTRU)moving between first and second Radio Access Technologies (RATs), themethod comprising: determining, by the NE, whether the WTRU has asession routed over the first RAT and the WTRU has become idle; and oncondition that the WTRU has a session routed over the first RAT and theWTRU becomes idle: sending, by the NE to a first Access Point (AP),context information to maintain by the first AP in accordance with thecontext information, a control plane connection for the sessionassociated with the WTRU, and suspend the user plane connection for thesession associated with the WTRU prior to expiry of a timer, andsending, by the NE to a second AP, further context information toestablish by the second AP in accordance with the further contextinformation, a user plane connection for the session associated with theWTRU.
 19. An Access Point configured to serve a WirelessTransmitter/Receiver Unit (WTRU) moving between first and second RadioAccess Technologies (RATs), comprising: a timer, a transceiverconfigured to receive from a network entity context information aprocessor, in communication with the transceiver, and configured to, oncondition that the WTRU has a session routed over the first RAT and theWTRU becomes idle: (1) maintain, in accordance with the received contextinformation, a control plane connection for the session associated withthe WTRU, and (2) suspend the user plane connection for the sessionassociated with the WTRU prior to expiry of the timer.
 20. The AccessPoint of claim 19, wherein the processor is configured to release theuser plane connection for the session after expiry of the timer.
 21. TheAccess Point of claim 19, wherein the processor is configured tomaintain the control plane session associated with the WTRU prior to andafter the suspension of the user plane connection.
 22. The Access Pointof claim 19, wherein: the processor is configured to hand over to afurther AP, the user plane connection for the session associated withthe WTRU, a communication path being established at least between the APand the further AP; and the transceiver is configured to relay datapackets that are associated with the session via the establishedcommunication path towards the further AP.
 23. The Access Point of claim22, wherein the processor is configured to: maintain at least onewireless resource between the AP and the WTRU prior to the handover ofthe communication session; and discontinue the at least one wirelessresource between the AP and the WTRU.
 24. A Network Entity (NE)configured to serve a Wireless Transmitter/Receiver Unit (WTRU) movingbetween first and second Radio Access Technologies (RATs), comprising: atransceiver; a processor, in communication with the transceiver, theprocessor being configured to determine whether the WTRU has a sessionrouted over the first RAT and the WTRU has become idle; and on conditionthat the WTRU has a session routed over the first RAT and the WTRUbecomes idle, the transceiver is configured to: send to a first AccessPoint, context information to maintain by the first AP in accordancewith the context information, a control plane connection for the sessionassociated with the WTRU, and suspend the user plane connection for thesession associated with the WTRU prior to expiry of a timer, and send toa second AP, further context information to establish by the second APin accordance with the further context information, a user planeconnection for the session associated with the WTRU.